[Koha-devel] rel_2_0 CVS branch

Wed Dec 17 09:02:02 CET 2003

On Wed, 17 Dec 2003, MJ Ray wrote:

> On 2003-12-16 23:53:22 +0000 Pat Eyler <pate at 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.
>

As Chris said in his follow-up, the rel_2_0 tree is going to be for
bug-fixes, so please commit fixes there.  One place that we could really
use some 'bug-fixing' is in the docs.  If anyone can get involved there,
Nick would certainly appreciate it.

It'd probably be better if we announced the impending branch creation
24-48 hours in advance next time, and explained things then.  Chris and I
will try to be more clear.

> > [...] 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.html#BRANCHES
> gives one view on this.

There's a fine line to walk here, and I'm not sure which side I come down
on.  On the one hand, it's good to get new features (even the small ones)
into play quickly.  On the other, stablilization needs to happen.  Even a
6 month wait for our end users to get new features is an awfully long
time.  In the 1.2 tree, we made the decision that small, safe features
could be added into the stable tree without hurting things (much) and
without making people wait for 2.0.0.  I still tend toward this feeling,
but am open to hearing reasons why it's sub-optimal.

I'm going to wait to talk about a 2.2 RM for another email, as I need to
let that percolate a bit longer.  We do need to make sure that
bug/security fixes get merged back into head regularily though.  Weekly or
so is probably a good target.

>
> > 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.

I like this idea, and it's about what I was shooting for.  Perhaps we
should follow the gcc model.  2 months of open development on HEAD, then
cut rel-2-2, 2 months of rel-2-2 specific development with 2.1.X releases
being made, then 2 months of rel-2-2 bug squashing, culminating in a 2.2.0
release about 6 months after 2.0.0.  rel-2-4 would be cut at the same
point as rel-2-2 enters the 'bug squashing' phase.  We can carry this
pattern forward ad infinitum.

Planning on 2.0.1 at 1 month, 2.0.2 at 3 months, and 2.0.3 at 5 months
would give us a good timeline for collecting, testing, and QAing bug fixes
and minor new features in the stable tree while development goes on on
HEAD and then rel-2-2.

>
> > 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 don't really see them as part of the release series, more an early look
at what's going on for people not able to or interested in tracking cvs.
I think following the rolling six month outline above would handle our
needs fairly well though.

> > 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.

That's true for this conversation.  I hope there will be some reasonable
conversation around what we want to develop on those lists (and this one)
though.

-pate

>
> --
> 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 at jabber.at
>   Creative copyleft computing services via http://www.ttllp.co.uk/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>