Raspiblitz: Change to Gitflow Process - get rid of master branch
The idea is to basicall switch more to a GitFlow process instead working all the time on a branch release.
So the idea would be:
- development is done on the dev branch, new features should be done on single feature branches and merged into dev once ready.
- when a release of a new main-version comes closer (like v1.6 to v1.7), a new release branch gets created from dev with the first release candidate - the RCs and final version sd card will be build from this branch so that calling the "patch" command will by default sync code with that branch
- the idea is that all minor-releases (like v1.6.1 or v1.6.2) will all work with the same 'build_sdcard.sh' script so that code could be updated by just calling 'patch' (emergency updates may break this rule) - for every major update a sd card update is mandatory
- once a release is ready, that release branch will be set as the "default" branch on GitHub (so its shown to a fresh user)
- hot fixes and features for minor verisons will be created as single branchs and once ready will be merged into the latest release branch & the dev branch
Also this way we dont need a "master" branch at all - following the idea: "no masters, no slaves"
rootzoll
All 14 comments
I support this..! @openoms objections?
frennkie
on 2 Aug 2020
No objections. It all makes sense. 馃憤
openoms
on 2 Aug 2020
Just a thought: If we get rid if the "master" branch and instead switching which release branch will be the "default" to display ... will that make it harder for people on GitHub to follow the project (from the view of the github build in social functions)?
rootzoll
on 4 Aug 2020
Maybe keep the master branch to contain the equivalent from the latest SDcard release.
Development in dev + feature branches for bigger projects.
Forked to versioned branches for RC images.
Releases (including minor ones) to be tagged from master to keep clear history.
openoms
on 18 Aug 2020
Just a thought: If we get rid if the "master" branch and instead switching which release branch will be the "default" to display
In my opinion it should be the branch of the currently released SD card (currently v1.6). Makes much more sense for me than the current practice of showing master which might have many changes (also to readme.md) that are not relevant to "normal users".
Maybe keep the master branch to contain the equivalent from the latest SDcard release.
We discussed this and the latest SDcard state should be in the branch for that release (e.g. v1.6)
@rootzoll so you now created v1.7 branch (which I wouldn't have) but not dev .. how should we continue? :-D
frennkie
on 5 Sep 2020
Ok.. I merged v1.7 into master, created dev and removed v1.7.
frennkie
on 5 Sep 2020
Yeah I think everybody is confused now ... please lets make a group call and get all in sync on this.
rootzoll
on 8 Sep 2020
I always thought that a v1.6 branch will always work with a v1.6 sd card build and thats how the "hot update" works because the git on a v1.6 RaspiBlitz is set to the v1.6 branch.
And master is the latest "released code" but now there are already changes for v1.7 in there .. that even will not be part of v1.6.1.
I can understand that changing to a more "common model" is easier for the rest and I am open to that ... but now in the middle of perparing v1.6.1 I dont know anymore where to merge what. @openoms @frennkie please lets make a video call soon to get on the same page here again. Thanks.
rootzoll
on 8 Sep 2020
Today we deleted the "master" branch on the RaspiBlitz GitHub repository .. the default branch is now always the latest release branch. We did it mostly because of practical reasons ... but also because we dont believe in masters ;)
https://twitter.com/rootzoll/status/1303404320105402376?s=20
\o/ 馃憤
I think we agreed that we need to be "disciplined" in two aspects:
- if changes (e.g. hotfixes) are made to older release branches (e.g.
v1.6) then those change should immediately also be included indev - after a branch for a future release (e.g.
v1.7) is created we should agree on which changes should go into bothdevand the new branch and which changes are for the future (and should therefore still be keeped in a separate feature branch).
frennkie
on 8 Sep 2020
To make it easier to test PRs on a RaspiBlitz I crreated this PR: #1531
rootzoll
on 10 Sep 2020
How about an "extra"/hidden menu where certain things are that "normal" people don't need... but which are useful for contributors and the repo owner..?!
Hidden menu would be activated via a switch in raspiblitz.conf.
frennkie
on 10 Sep 2020
I think the update > patch-menu is already like a "hidden menu" normal users will not be bothered with. To hide it even more is maybe a bit too much. I would either make it easier to call it directly with a terminal command like "github" that brings you directly in the menu where you find all "contributer" options.
rootzoll
on 14 Sep 2020
Now using branches for developing features and testing on my raspiblitz I added the "github" command to quickly jump to the menu to canhe branches etc. Quite usefull. Will merge into v1.6.1
rootzoll
on 16 Sep 2020
OK .. as final part of v1.6.1 release document the new process and the github options.
rootzoll
on 8 Oct 2020
Related issues
Kixunil
路
3Comments
fluidvoice
路
3Comments
pkclyoni
路
3Comments
Himbeergeld
路
3Comments
rootzoll
路
4Comments
Most helpful comment
\o/ 馃憤
I think we agreed that we need to be "disciplined" in two aspects:
v1.6) then those change should immediately also be included indevv1.7) is created we should agree on which changes should go into bothdevand the new branch and which changes are for the future (and should therefore still be keeped in a separate feature branch).