On Thu, Mar 26, 2015 at 19:12 -0300, Bruno Oliveira wrote: > 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?
Doc changes go to "dev" if they relate to a feature that is only in 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 > > 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. > 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? Yes, i now changed CONTRIBUTING to differentiate between forking/merging with ``default`` and ``pytest-VERSION-MAINTENANCE-branch``. Indeed, we should then regularly merge all bug fixes from the 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. Yes, let's do it the same way. I updated the pull request and also enhanced styling a bit to make code/literals be more recognizable (the release doc was hard to read, otherwise). Btw, what should this release-checklist PR be merged with? I guess first with the maintenance version so that it goes to "pytest.org/latest" and then also be ported to ``default``. Sigh, this doc versioning is a bit icky (which is why it was messed up in the past, pushing changes too early). holger > 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 > > -- 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
