Hi Floris, i updated the PR at:
https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff i suggest you merge it with default and then branch off pytest-2.7 and bump the version number for the default branch in _pytest/__init__.py to "2.8.0.dev1". Indeed, the symlinking of "latest", "dev" currently is a manual activity. Also, the release checklist is not totally precise wrt to which branch a release is done from. There are slight differences if you are doing a micro or minor release but i'd like to care about that later (or someone else can). For now, i'd be happy if we merge the release-checklist as it is much better than not having documented anything about the release process :) holger On Wed, Apr 01, 2015 at 09:43 +0100, Floris Bruynooghe wrote: > 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. -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
