[Biopython-dev] Rolling new releases

[Brad Chapman]

Hi Peter;

> http://biopython.org/wiki/Building_a_release
> 
> i.e. Maybe in a few months time I (or Michiel) can say "Right, CVS
> freeze while XXX does the release", where person XXX gets to scan the
> documentation, double check the NEWS files, check the unit tests etc,
> before putting together the packages and uploading them to the server.
>  And maybe then hand over to our "News Coordinator" to do the release
> announcement?  Having more people involved will make it take a little
> longer, but should mean less minor things get missed (e.g. a typo in
> the NEWS file, or a broken unit test specific to a particular OS or
> version of python).

It would be great to have others involved in rolling releases.
BioPerl often passes the Release Manager hat around for release to
release, and perhaps we can get the same tradition going here. I
like the idea of people volunteering for this.

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:

- Remove support for older python versions, which would eliminate
  all those windows installers. I will write more about this in your
  other thread.

- Eliminating the beta releases. Biopython is developed as stable
  in Git/CVS, so gets testing that way on developer machines. Are we
  getting enough feedback from betas to make them worthwhile?

- Automate building the docs nightly/weekly on biopython.org. If the
  Tutorial/epydoc stuff is a lot of work, we could work up a script
  and cron to eliminate this part.

That's from my fuzzy memory of rolling releases.

Brad