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 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. If that makes sense i can modify the release-checklist PR accordingly. best, holger > So what this means for the current release-checklist pull-request is that > it could be used to create the pytest-2.7 branch. And then we can bump > versions in default to 2.8.0.dev0. > > Hope that all makes sense. > > > On 27 March 2015 at 08:37, holger krekel <hol...@merlinux.eu> wrote: > > > On Thu, Mar 26, 2015 at 19:12 -0300, Bruno Oliveira wrote: > > > > > > This means that even little feature additions or changes in behaviour > > > > would neccessarily need to go to pytest-2.8. In the past, i have > > > > allowed such little additions where i was pretty sure they wouldn't > > break > > > > things into micro releases > > > > > > According to Semantic Versioning, strictly speaking changes in existing > > > behavior would have to bump the minor number (except bugs, which would > > > bump MICRO). Not sure how people feel about it, but some > > > (myself included) like to know that they can safely update a library/tool > > > without having to review your code for usage changes (not that I've ever > > had > > > this problem with pytest, mind you). MAJOR should be updated for > > > backward-incompatible changes, but I don't see that happening anytime > > soon. > > > > > > In the end of the day, I guess just having a couple of guidelines/rules > > in > > > place > > > is that everyone agrees on is good enough. > > > > Note that virtually pytest releases are supposed to be backward compatible. > > And even bug fixes can introduce backward compat problems. > > > > I agree with Bruno that semantic versioning is a nice standard to follow > and people are familiar with it these days. So any bugfixes for 2.7 go to > a pytest-2.7 branch while any new features go into default. I realise that > this means most releases will be 2.X.0 with an occasional 2.X.1 or so and > probably never a 3.X.0, but I think that's perfectly fine. > > > Regards, > Floris -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
