On Jul 4, 2007, at 9:53 AM, Chris Fields wrote:
> we start having fixed,
> regularly timed dev releases like Parrot, monthly or bimonthly (quite
> common on CPAN), with brief release reports on which bugs have been
> fixed, code has been added, so on. Not every bug has to be fixed per
> dev release; if that were true there would never be releases for some
> of the XML parser packages. No RCs for dev releases (it's a dev
> release!). These would be 1.x.y. We can then, every once in a
> while, have a bug-squashing session, hackathon, etc, and have regular
> non-dev release (1.x) that all core devs accept and that passes a
> particular milestone.
Regardless of whether we split or don't, I think these ideas of
adding a little more structure to BioPerl's development cycles --
especially having bug-squashing and hacking sessions, where we all
band together and commit some time to cranking through a bunch of to-
dos -- would be beneficial, particularly as a means to keeping a
certain basal level of momentum in BioPerl.
Dave