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.)