[pytest-dev] release checklist / de-monopolizing release process

[holger krekel]

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 <holger at 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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >

-- 
about me:    http://holgerkrekel.net/about-me/
contracting: http://merlinux.eu