Tox: RFC: start using a development branch

[obestwalter]

Background: I started doing releases with release candidates to protect users from breakage. There seem to be quite a few people who install tox with --pre already, so this seems to work well enough. The problem is that I like to let the rcs hang around for a while and in this time more changes are being merged which introduce new risks.

IMO the simplest way keeping both (long running rcs and merge new changes quickly), would be for me to create a release branch from which I release the rcs where I (or whoever else might do the release) only merge bug fixes for the rc or changes where I feel really confident about. When the release is done the branch can be removed. So master stays the default development branch and there is a relatively short lived release specific branch then.

My main concern is to balance stability with speed of progress (by whatever definition of progress). My personal priority for tox is mainly stability and to not break other peoples builds unnecessarily. I am quite happy with what tox is doing already and that is why I am not even too keen to churn out new features. More and more can and should be done via plugins anyway. I appreciate though that the project is growing and don't want to slow down the development unnecessarily, so this is why this hybrid approach seems appropriate to me.

I would appreciate some feedback about this.

[The-Compiler]

Sounds good to me - I definitely prefer having stable/release branches (using master for development, and either merging the release branch to master or cherry-picking commits from master to the release branch) to having a development branch (like features in pytest). IMHO, if master isn't the main point of development, that causes unnecessary friction for contributors.

[gaborbernat]

I would prefer using the master as development, and maybe have an rc branch for release candidates. Fixes added to rc branches can then be cherry picked onto master.

[obestwalter]

Sounds good to me - I definitely prefer having stable/release branches (using master for development, and either merging the release branch to master or cherry-picking commits from master to the release branch) to having a development branch

I would prefer using the master as development, and maybe have an rc branch for release candidates.

So, although we all phrase it a bit differently, we all want the same, if I understand it correctly.

From the perspective of the average contributor nothing would change at all. PRs are opened against master and all normal development happens there. The person who carries out a release creates a branch (e.g. rcX.Y.Z) where they merge in updates until the release is final at which point the branch can be deleted. Ideally nothing will flow back from rc to master as all fixes and development happen on master and are cherry picked into the rc branch.

Right?

[gaborbernat]

correct :-)

[nicoddemus]

The workflow I read here is clear to me when dealing with a release candidate, when it is decided that in a few weeks say 4.0.0-rc1 will be released, a branch is created and any critical fixes pertinent to 4.0.0-rc1 are integrated into master and cherry-picked to 4.0.0-rc.1.

But how to deal with bug-fixes from now on? For example, after 4.0.0 is out, a week passes and new feature is integrated into master, but then the very next day a critical bug is found which demands a quick new release. Following semantic versioning, we will need to make a 4.1.0 released right away because of the new feature. That's the reason we have the features and master branches in pytest: to separate bug-fix releases from minor releases with new features; without this separation practically every new pytest release would be a new minor release, because small features are integrated all the time.

It is not my intention to get in the way of the discussion, I just want to understand the reasons and mechanics of the proposal to make sure I'm not missing something. 😄

[The-Compiler]

FWIW what I do in qutebrowser is having e.g. a v4.0.x branch which is open at least until the v4.1 release. If there are fixes critical enough to warrant a v4.0.2, I fix stuff in master and cherry-pick them there. So, same concept, but the branch stays there a bit longer.

It's a bit more work because you need to cherry-pick fixes after merging them to master (but at least in qutebrowser, it's rare that I get PRs for bugfixes :laughing:) and the git describe output confuses some people (because the v4.0.2 wasn't released from the master branch) - but in return, master is always the right place for contributions, and you don't have to deal with merges (where you forgot the context of the changes) because you cherry-pick stuff right away. Works great for me, FWIW.

[obestwalter]

Thanks for your input @nicoddemus - tox is in a bit of a different place. The development activity on pytest is simply mindboggling, so that approach makes sense there, I guess (I don't have detailed insights though - I only watch pytest development from afar).

@The-Compiler wrote:

FWIW what I do in qutebrowser is having e.g. a v4.0.x branch which is open at least until the v4.1 release. If there are fixes critical enough to warrant a v4.0.2, I fix stuff in master and cherry-pick them there. So, same concept, but the branch stays there a bit longer.

This is exactly what I intend to do (today to be exact) :)

[obestwalter]

Thanks for your feedback. I started doing it this way now. I created release-3.0.X from the state of the rc2 release and cherry picked what is necessary for rc3, which hopefully will be the last rc.

This way of working will reduce the friction for me to make more frequent releases, as I have a sane way of dealing with bugfix vs feature releases now. Merging changes by other team members can be done without concern for the current release process that might be going on.

[nicoddemus]

CPython has https://github.com/python/miss-islington which helps with porting bug fixes across maintenance branches (for example python/cpython#6283). Not suggesting that tox should do the same given that we have a much smaller number of PRs to deal with, but I thought that was cool and wanted to share. 😁

[nicoddemus]

... and look what I found: https://github.com/MeeseeksBox/MeeseeksDev 😁 (found in https://github.com/dateutil/dateutil/issues/653#issuecomment-376409525, thanks @Carreau). It has a @MeeseeksDev backport [to] {branch} command which does exactly what is described here for the maintenance branches. Plus it seems you don't even need to host this yourself, just registering the repository is enough.

Might be worth giving it a try after all. 😁

[Carreau]

Feel free to use and report issue. Right now it requires push permissions (limitation of GitHub integrations). I have idea how to not require that.

You can also modify the milestone descriptions to auto backport on merge.