<div dir="ltr">Hi,<div><br></div><div>> If we assume that pytest-2.7.X will be "bugfix only" we could</div><div>> tie its doc target to "latest" and ask everybody who does doc enhancements</div><div>> to target their PRs to "latest".</div><div><br></div><div>Seems reasonable to me, but what about doc fixes for features which will</div><div>be released only on 2.8.0?</div><div><br></div><div>> This means that even little feature additions or changes in behaviour</div><div>> would neccessarily need to go to pytest-2.8. <span style="font-size:12.8000001907349px">In the past, i have</span></div><span style="font-size:12.8000001907349px">> allowed such little additions where i was pretty sure they wouldn't break</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> things into micro releases</span><div><br></div><div>According to Semantic Versioning, strictly speaking changes in existing </div><div>behavior would have to bump the minor number (except bugs, which would</div><div>bump MICRO). Not sure how people feel about it, but some  </div><div>(myself included) like to know that they can safely update a library/tool</div><div>without having to review your code for usage changes (not that I've ever had</div><div>this problem with pytest, mind you). MAJOR should be updated for </div><div>backward-incompatible changes, but I don't see that happening anytime soon.</div><div><br></div><div>In the end of the day, I guess just having a couple of guidelines/rules in place </div><div>is that everyone agrees on is good enough.</div><div><br></div><div>Back to which PRs should target, in "contributing.txt" it is recommended to </div><div>always target "latest". My knowledge of Mercurial is </div><div>limited so please correct me if I'm wrong, but doesn't that make it harder to </div><div>port bug fixes to a "maintenance" branch?</div><div><br></div><div>Just to share what we have used in Git, maintenance branches are used</div><div>as targets for bug fixes, while master should be target for new features. This way, </div><div>you can easily merge maintenance into master to port bug-fixes to the future release,</div><div>while keeping a possible maintenance release free of new features.</div><div><br></div><div>Cheers,</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 10:23 AM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
One afterthought: i struggle a bit to find a good workflow especialy<br>
related to docs.<br>
<br>
There are some changes to the docs which are release independent,<br>
for example updating the current header info for "Adopt pytest month".<br>
<br>
And there are changes which go together with not yet released code changes.<br>
<br>
If we assume that pytest-2.7.X will be "bugfix only" we could<br>
tie its doc target to "latest" and ask everybody who does doc enhancements<br>
to target their PRs to "latest".<br>
<br>
And for pytest-2.8 (trunk?) we'd put it to "dev".<br>
<br>
This means that even little feature additions or changes in behaviour<br>
would neccessarily need to go to pytest-2.8.  In the past, i have<br>
allowed such little additions where i was pretty sure they wouldn't break<br>
things into micro releases (working MAJOR.MINOR.MICRO naming here).<br>
<br>
With pytest-2.7.0 a lot of the internal hook calling machinery changed<br>
along with new hookwrapping mechanisms -- given the many plugins and<br>
hook usages in test suites this is a bit of a risky change and therefore<br>
i bumped the minor number.<br>
<br>
Thoughts or opinions on this welcome.<br>
<br>
Whatever we come up with, we may update "contributing.txt"<br>
to reflect "PR targets".<br>
<br>
best,<br>
holger<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Mar 26, 2015 at 13:12 +0000, holger krekel wrote:<br>
> Hi committers and friends of pytest :)<br>
><br>
> to de-monopolize the knowledge of releasing pytest i just created<br>
> a PR with a first stab at a release checklist:<br>
><br>
> <a href="https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff" target="_blank">https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff</a><br>
><br>
> It doesn't explain how to use ``devpi``, maybe this tutorial helps:<br>
><br>
>     <a href="http://doc.devpi.net/latest/quickstart-releaseprocess.html" target="_blank">http://doc.devpi.net/latest/quickstart-releaseprocess.html</a><br>
><br>
> Ideally more of the release process would be automated, am open to PRs<br>
> and scripts doing it.<br>
><br>
> Also, i'd like to add some more people's SSH key to the "pytest-dev"<br>
> account on ``<a href="http://pytest.org" target="_blank">pytest.org</a>``.  Brianna, Ronny and me can currently "make install"<br>
> the docs there.  Floris, Anatoly, Andreas, Bruno: please send me your public<br>
> ssh-key and your PYPI handle so you are technically able to do a release.<br>
> Anyone else who wants to and is in the current pytest-dev committer<br>
> group is invited as well :)<br>
><br>
> best,<br>
> holger<br>
><br>
><br>
> --<br>
> about me:    <a href="http://holgerkrekel.net/about-me/" target="_blank">http://holgerkrekel.net/about-me/</a><br>
> contracting: <a href="http://merlinux.eu" target="_blank">http://merlinux.eu</a><br>
> _______________________________________________<br>
> pytest-dev mailing list<br>
> <a href="mailto:pytest-dev@python.org">pytest-dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/pytest-dev" target="_blank">https://mail.python.org/mailman/listinfo/pytest-dev</a><br>
><br>
<br>
--<br>
about me:    <a href="http://holgerkrekel.net/about-me/" target="_blank">http://holgerkrekel.net/about-me/</a><br>
contracting: <a href="http://merlinux.eu" target="_blank">http://merlinux.eu</a><br>
_______________________________________________<br>
pytest-dev mailing list<br>
<a href="mailto:pytest-dev@python.org">pytest-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pytest-dev" target="_blank">https://mail.python.org/mailman/listinfo/pytest-dev</a><br>
</div></div></blockquote></div><br></div>