On 2003-12-16 23:53:22 +0000 Pat Eyler <pate@eylerfamily.org> wrote:
Please, let me second the comments below. We need to be really careful about which branch we're working in now. If you are doing bug fixes, please check out the rel_2_0 tree and do your work there.
This is the opposite of how I understood Chris's message. I have committed the last DBI fixes in C4 to HEAD and I ask Paul to backport it, please. I will now continue into the other scripts, but I'll not commit more until I know where I am supposed to be going.
[...] we've got a lot of little things that could be added into 2.0.1 (and beyond) -- things like new reports, rssKoha, and other incremental or small improvements.
New features really should go into 2.1, in my opinion, unless they are so essential as to be bugs in 2.0. The stable branch must be allowed to stabilise. The 2.2 RM should check all fixes to rel_2_0 and apply relevant ones to HEAD. That means that someone should act as 2.2 RM immediately, even if they are not going to be the real RM. http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO... gives one view on this.
Ideally, I'd like to see us cutting 2.2.0 between August and October of 2004, with four or five 2.0 minor releases during that timeframe (more if we have security problems to fix). How does that sound to everyone else?
I'd set a target of 2.0.0+6 months. That probably means feature freeze at +4 or +5 months. This should make "no new features inside 2.0" rule a bit more bearable.
During 2.2 development, I wonder if we should avoid 2.1.X releases for a while and just cut weekly snapshots until we've stabalized a bit. Does that sound reasonable? Is there a better way?
I think that's the 2.2 RM's call. Personally, I don't see much value in simple snapshots being classed as part of a release series. Might as well practice the release process or just let people use CVS. The 2.1.0 release could be a naive integration of rssKoha and similar simple features. Other features should exist outside the main 2.1 tree until they are working.
I've expanded this mail to include the kohabiz and koha2010 mailing lists.
I've trimmed, as I doubt they care about the mechanics of releases and will be more concerned with features and times. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/