Often, it is difficult to understand into which branch bugfixes should go. E.g. at the moment, after 1.3.1 is released, and we are working on 1.4.0, bugfixes should go into master to be included in the upcoming 1.4.0 release and not into maintenance_1.3.x. This might be a bit confusing for contributors.
What about a dedicated branch simply named maintenance? We could set the tip of this branch to master now. After the release of 1.4.0 the tip stays on 1.4.0. After the bugfix release of 1.4.1 we can merge into master and set the tip to master and so on. Still, the individual PRs have to be rebased if the tip changes, but the base branch has not to be updated and it is always perfectly clear that bugfixes go into the maintenance branch.
Even better would be an alias maintenance for master for the period between the release of 1.3.1 and 1.4.0, but that is not supported by github, I think.
I think the current way is clean and it is how most notable comparable projects handle it (matplotlib, scipy, …). I’m not sure.. is it really confusing people? In any case, I see what you’re saying and since we really don’t maintenance older release cycles but rather just the current one for the most part, if you want to change it like that, I won’t stop it.
Or we could keep the individual maintenance branches, but in addition add that simple maintenance branch whose tip we can adjust like you proposed.
I am not sure exactly how it will look like in PRs that are based on that one, if we push around its tip.. since the tip should only get moved to later parts in the history it should be OK, I guess.
In general, people can always start with opening an issue and asking how to start out with a PR, if there’s confusion.
Personally, if I make a PR for a foreign project, I usually just make a guess which branch to use and if its the wrong one, I just rebase later. If I weren’t comfortable doing that, I’d just ask before starting out.
OK, we can keep it in mind, and for now keep it as it is. I just looked at scipy and numpy. I think, everything is committed to the main branch first for these projects. Only later relevant commits are cherry-picked and added to the maintenance branches. (In mpl a bot is involved.)
Came here looking for a similar answer-- which branch to use? I admit I am not great at git but it’s not always clear.
Issue currently is that a new feature PR based on master needs a fix from maintenance.. requires rebasing again which isn’t too big a deal if you know what you’re doing (not always me) but made me rethink why it’s done this way for a modestly sized package.
Thinking as well from a user’s perspective. If a serious bug gets fixed or a great new feature is added, it might not be clear for most people to know where to access it or how or how to merge two disparate branches to simply “get the latest”.
Just having a single master for any interim additions or fixes seems a lot easier overall, but as usual I am probably not appreciating some details. In the least I think it would definitely help to just have the one maintenance branch.
The reasoning for having two separate “main” branches is simple. We want/need to be able to separate
bug fixes, which result in minor release updates on the last stable release from..
new features, which will result in a major release and are not supposed to go into the minor bug fix releases
Feature releases are much more work to push out and get ready and sometimes bugs (or package incompatibilities in new releases of dependencies etc.) that get reported are quite breaking and need a fast(ish) reaction and minor release which can be done relatively fast if separated from new feature changes.
This is a non issue, we (/me) regularly merge the maintenance branch back into master branch. I can do that right now real quick.
We have some stuff in the installation wiki how to make an installation from e.g. master branch or make a dev installation to work with a git clone to commit changes to history. If you feel like this information should be presented differently, please don’t hesitate to change the installation wiki directly.
Merging “two disparate branches” should not really be necessary for the user. We can try to merge maintenance branch more often into master if needed, if thats needed you can also just open a PR proposing to merge maintenance branch into master branch to notify us (/me) and we can take care of it.
Having a single development branch implies that new features are mixed with bug fixes. That means if a bug fix release needs to be done on the stable release, we’d have to create a dedicated release branch based on the release tag and then look up commit hashes of all individual bug fix commits and backport them on that release branch. that might be doable if it’s about a single bug fix, but if a handful bug fixes have accumulated this becomes a nightmare.
