Hi, > If we assume that pytest-2.7.X will be "bugfix only" we could > tie its doc target to "latest" and ask everybody who does doc enhancements > to target their PRs to "latest".
Seems reasonable to me, but what about doc fixes for features which will be released only on 2.8.0? > 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. Back to which PRs should target, in "contributing.txt" it is recommended to always target "latest". My knowledge of Mercurial is limited so please correct me if I'm wrong, but doesn't that make it harder to port bug fixes to a "maintenance" branch? Just to share what we have used in Git, maintenance branches are used as targets for bug fixes, while master should be target for new features. This way, you can easily merge maintenance into master to port bug-fixes to the future release, while keeping a possible maintenance release free of new features. Cheers, On Thu, Mar 26, 2015 at 10:23 AM, holger krekel <hol...@merlinux.eu> wrote: > > One afterthought: i struggle a bit to find a good workflow especialy > related to docs. > > There are some changes to the docs which are release independent, > for example updating the current header info for "Adopt pytest month". > > And there are changes which go together with not yet released code changes. > > If we assume that pytest-2.7.X will be "bugfix only" we could > tie its doc target to "latest" and ask everybody who does doc enhancements > to target their PRs to "latest". > > And for pytest-2.8 (trunk?) we'd put it to "dev". > > 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 (working MAJOR.MINOR.MICRO naming here). > > With pytest-2.7.0 a lot of the internal hook calling machinery changed > along with new hookwrapping mechanisms -- given the many plugins and > hook usages in test suites this is a bit of a risky change and therefore > i bumped the minor number. > > Thoughts or opinions on this welcome. > > Whatever we come up with, we may update "contributing.txt" > to reflect "PR targets". > > best, > holger > > > On Thu, Mar 26, 2015 at 13:12 +0000, holger krekel wrote: > > Hi committers and friends of pytest :) > > > > to de-monopolize the knowledge of releasing pytest i just created > > a PR with a first stab at a release checklist: > > > > > https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff > > > > It doesn't explain how to use ``devpi``, maybe this tutorial helps: > > > > http://doc.devpi.net/latest/quickstart-releaseprocess.html > > > > Ideally more of the release process would be automated, am open to PRs > > and scripts doing it. > > > > Also, i'd like to add some more people's SSH key to the "pytest-dev" > > account on ``pytest.org``. Brianna, Ronny and me can currently "make > install" > > the docs there. Floris, Anatoly, Andreas, Bruno: please send me your > public > > ssh-key and your PYPI handle so you are technically able to do a release. > > Anyone else who wants to and is in the current pytest-dev committer > > group is invited as well :) > > > > best, > > holger > > > > > > -- > > 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 > > > > -- > 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 >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
