On 1 April 2015 at 08:21, holger krekel <[email protected]> wrote: > Hi Floris, > > thanks for the summary. Comments inline. > > On Tue, Mar 31, 2015 at 23:55 +0100, Floris Bruynooghe wrote: > > Hi, > > > > I started doing inline replying but I think it got confusing. I mostly > > agree so far, including with semantic versioning, but would like to > > summarise the usage of branches how I think/understand it should work: > > > > Each release has a release/maintenance branch: pytest-2.6, pytest-2.7 > etc. > > This is where the next bugfix release is prepared, e.g. 2.7.1. > > > > The default branch is where the next feature release is prepared, e.g. > 2.8. > > > > Any bug fixes for a release should be committed to these release > branches, > > once committed there they should be merged to the default branch. I > think > > whoever merges the pull request is responsible for also merging it into > > default. > > > > Any live website updates should be committed to the last release branch > > which should be hooked up to the "latest" doc-install target. At any > point > > we should be able to install the docs from the last release branch to the > > live site. > > This does mean sometimes doc changes for a bugfix release appear before > the > > bugfix is released. Maybe we should address this in the long term by > > splitting off the website to a different repo from the docs, so you serve > > http://pytest.org separate from http://pytest.org/latest and > > http://pytest.org/dev. That way out-of band updates can happen. > > > > This has a slight influence on the release procedure: When creating a > new > > feature release one does the final commits to set the doc-install target > to > > "latest" in a new branch, e.g. pytest-2.8, then tag the release. Once > the > > release is tagged versions can be bumped in the release branch, e.g. > > 2.8.1.dev0 as well as the default branch, e.g. 2.9.0.dev0. The main > > downside of all this is that it will produce annoying merge conflicts in > > the changelog for bugfixes which we will have to manually resolve every > > time. > > The most complicated thing to handle seems to be documentation. What > about automating/simplifying things: > > - automate setting of version/release in conf.py from setup.py (or > include all version-bumpbing code in a extra/set_version.py script) > > - modify the Makefile to not have a static "SITETARGET" but use the > "release" > version found in conf.py to determine the target: > - X.Y.Z[.devN] will select pytest.org/X.Y as a target > - symlink pytest.org/dev to 2.8 and pytest.org/latest to 2.7 > and on minor feature release change the symlinks >
Sounds about right, the only thing I'm not sure is how to (automatically) maintain the symlinks. Or is this something that would end up on the release checklist? > One underlying assumption is all doc changes in the "pytest-2.7" > maintenance > branch will be bugfixes in the docs and are fine to be seen immediately. > > There is one concern from my side which is that if we are strict about > only letting bugfixes into micro releases we'll end up with two active > branches to manage and possibly to release from. As we usually design > all changes to be backward-compatible we should retire 2.7-maint as soon > as 2.8 is out. Yes, given how py.test's backwards compatibility works we can retire pytest-2.7 as soon as 2.8 is released. So only regressions would end up on a release branch normally and the overhead shouldn't be too high (provides an incentive not to make mistakes :-) > > If that makes sense i can modify the release-checklist PR accordingly. > Fine with me.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
