[Biopython-dev] Rolling new releases

[Peter Cock]

On Thu, Apr 23, 2009 at 1:53 PM, Brad Chapman <chapmanb at 50mail.com> wrote:
> Hi all;
>
>> > It would also be worth thinking about what the worst parts of
>> > building the releases are and seeing if we can automate or eliminate
>> > them. A few things that I can think of:
>
> [Brainstorming a few suggestions]
>
> I feel like I derailed from the main point by making suggestions.
> Separate from a debate about betas and version support and
> documentation -- how can we make releases easier to roll?
>
> Peter, this started when you mentioned that rolling the release
> felt kind of painful and it would be great if others would pitch in.
> The idea of soliciting volunteers as release coordinators is great.

I didn't mean painful, so much as time consuming - but this was mostly
coordinating final polish/bug fixes and documentation.  This kind of
thing requires some debate and judgement calls, and will be different
for every release.  I spent quite a lot of time on documentation for
things which I really wanted to get into the Tutorial that shipped
with the release (some of which should have happened earlier, so this
was partly my own fault).

In terms of getting the documentation updated for each release, this
would be less effort if we as a group were more diligent about putting
things in the tutorial and/or docstrings as we go along.  It's
important that nice new features are demonstrated, otherwise no-one
will know they are there without reading the code itself or from
following the mailing list discussions carefully.

> In addition to that, we should think about streamlining the release
> process -- what are the parts we can get rid of and still have high
> quality releases? Peter, since you are doing them right now, what
> are your thoughts?

The complicated bit is getting the code and documentation in CVS
ready, and that is harder to delegate.  Once that is done though, the
actual release process is fairly straight forward - as documented here
- and could be delegated to anyone methodical with suitably setup
development machine(s):
http://biopython.org/wiki/Building_a_release
Maybe some of the release process could be automated literally as a
script - but doing each step methodically by hand and checking as you
go is wise.

For the release process, I'm basically proposing splitting this up
into up to three jobs:

(1) Coordinating final bug fixes and documentation in CVS.  This has
recently been handled by me or Michiel with most discussion on the dev
lists, and some module specific details off list, and this works and I
wouldn't change it.

(2) Once CVS is ready, building the documentation, doing the release
archives, doing epydoc, doing the Windows installers, tagging CVS, and
uploading to the website.  Part of the job would include scanning the
NEWS and DEPRECATED files, plus recent documentation to make sure
nothing was missed.  This can be delegated.

(3) Writing and publishing the release announcement on the news site
and email lists (with the timing coordinated with the people doing
jobs 1 and 2).  I suggest having our new news coordinators take over
this bit.

So, while historically (1), (2) and (3) have be done by one person I
think this could be split up into the "Release Director", "Release
Manager" and "News Coordinator" roles (perhaps with different job
titles?).

Peter