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. 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 <[email protected]> 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
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
