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

[holger krekel]

Hi Floris,

i updated the PR at:

https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff

i suggest you merge it with default and then branch off pytest-2.7 and
bump the version number for the default branch in _pytest/__init__.py to "2.8.0.dev1".

Indeed, the symlinking of "latest", "dev" currently is a manual activity.

Also, the release checklist is not totally precise wrt to which branch a release
is done from.  There are slight differences if you are doing a micro or minor release
but i'd like to care about that later (or someone else can).  For now, i'd be
happy if we merge the release-checklist as it is much better than not having
documented anything about the release process :)

holger

On Wed, Apr 01, 2015 at 09:43 +0100, Floris Bruynooghe wrote:
> On 1 April 2015 at 08:21, holger krekel <holger at merlinux.eu> wrote:
> 
> > Hi Floris,
> >
> > thanks for the summary. Comments inline.
> >
> > On Tue, Mar 31, 2015 at 23:55 +0100, Floris Bruynooghe wrote:
> > > 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.
> >
> > The most complicated thing to handle seems to be documentation. What
> > about automating/simplifying things:
> >
> > - automate setting of version/release in conf.py from setup.py (or
> >   include all version-bumpbing code in a extra/set_version.py script)
> >
> > - modify the Makefile to not have a static "SITETARGET" but use the
> > "release"
> >   version found in conf.py to determine the target:
> >   - X.Y.Z[.devN] will select pytest.org/X.Y as a target
> >   - symlink pytest.org/dev to 2.8 and pytest.org/latest to 2.7
> >     and on minor feature release change the symlinks
> >
> 
> Sounds about right, the only thing I'm not sure is how to (automatically)
> maintain the symlinks.  Or is this something that would end up on the
> release checklist?
> 
> 
> > One underlying assumption is all doc changes in the "pytest-2.7"
> > maintenance
> > branch will be bugfixes in the docs and are fine to be seen immediately.
> >
> > There is one concern from my side which is that if we are strict about
> > only letting bugfixes into micro releases we'll end up with two active
> > branches to manage and possibly to release from.  As we usually design
> > all changes to be backward-compatible we should retire 2.7-maint as soon
> > as 2.8 is out.
> 
> 
> Yes, given how py.test's backwards compatibility works we can retire
> pytest-2.7 as soon as 2.8 is released.  So only regressions would end up on
> a release branch normally and the overhead shouldn't be too high (provides
> an incentive not to make mistakes :-)
> 
> >
> > If that makes sense i can modify the release-checklist PR accordingly.
> >
> 
> Fine with me.

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