[OPEN-ILS-DEV] ***SPAM*** Re: Well, it's that time again ...

[Dan Scott]

On Tue, 2010-04-06 at 11:25 -0400, Mike Rylander wrote:
> ... time to talk releases.  This is meant to start the discussion, not
> to dictate a plan, mind you.  Please jump in if you feel so inclined.
> 
> So, here's what seems reasonable to me.
> 
>  * 1.6.0.4 -- Big bug fix release. It's just about ready, pending
> application of a fix for some Dojo Grid UI issues that is currently
> being tested.  I'd like to get that out ASAP, and I'm realistically
> targetting April 15.

Sounds great!

>  * 1.6.1.0 -- Big-ish feature release, specifically
> Booking/Reservation, along with all the fixes in 1.6.0.4.  This, too,
> is nearly ready, but there is at least one pointy bit in the code to
> smooth out (op-capture delay of temporally distant reservations -- we
> have a plan), and the matching documentation (I know!  Can you believe
> it?!) needs to be brought up to speed.  That's planned for (more or
> less) next week.  Realistic target for this, right now, seems like May
> 15.

The self-serve password reset interface should be usable in this
release, too, particularly given a May 15 time frame.

> Beyond that things get fuzzier, but there's more to plan.
> 
> So, we have trunk, which will become something-after-1.6.  I propose,
> because of the massive changes in both code and database structure,
> that we use the version number to help convey that this is largely new
> code and call it 2.0 when it's branched.  Also, in addition to the
> newness of the code and the DB changes, there's the fact that 1.6 has
> only been around for about 6 months.  Originally, 1.6 was going to be
> a short-lived stepping stone on the way to
> whatever-contained-acquisition.0, but it's taken on a life of it's own
> and is both divergent /and/ mature enough that we can reasonably
> expect some sites to stay on 1.6.something for a while.  As for a
> target date on this, well, an alpha look probable by August.
> 
> Which brings us to the possibility of a 1.6.2 series.  IMO, it would
> be worth considering a few trunk-only features for backporting to this
> hypothetical release stream.  For instance, if serials can reasonably
> be extracted intact, that would be a top contender in my mind.

I think serials support is already in 1.6.0.3 - unless there's something
I'm not aware of? (Entirely possible).

> Another would be the advances we've made with Action/Trigger that
> allow much more sophisticated setups and more intelligent, not to
> mention faster, processing of events.  A third example might be some
> of the Staff Client improvements, most likely the Circulation and
> Cataloging related changes, that are in trunk now or going into trunk
> over the next couple months.  That could make 1.6.2 a true stepping
> stone to 2.x, and give us the change to put some of the more often
> requested features (but not ACQ) into the field for real-world
> shakedown.  I wouldn't expect this until some time after the 2.0-alpha
> (or maybe even the 2.0.0.0 GA release) as we shouldn't let it drain
> resources from 2.0, but before the end of the year would be my hope.

If it's a stepping stone to 2.0, why not call it 1.8 and make that
clear? The differences between your proposed 1.6.2 and 1.6.1 seem much
larger than the differences between 1.6.1 and 1.6.0, and the only reason
I can think of to call it 1.6.2 is to provide some justification for the
continued usage of an x.y.z.A release naming scheme :)

> So ... Thoughts?
> 

I worry a bit about how many branches we (the relatively limited
community of developers) will have to actively maintain at a time. Let's
assume we push out a 1.6.2 release - would we be expected to backport
those fixes to 1.6.1, 1.6.0, 1.4.0...? And more importantly, test those
fixes to ensure that no regressions are introduced, in all of those
branches?

Let's review our release history:
* September 2006: 1.0 is released (yay!)
* October 2007: 1.2.0 is released - 13 months
* November 2007: 1.2.1 is released - 1 month
* May 2008: 1.2.2 is released - 6 months
* January 2009: 1.4.0 is released - 7 months
* November 2009: 1.6.0 is released - 10 months
* May 2010: 1.6.2 (proposed) - 6 months

I'm not sure we have any project commitments to how many release
branches we support at a given time, but from the current downloads
directory it looks like two: 1.6 and 1.4. Given the pace of our major
releases, I suggest we jump directly to 1.7 instead of 1.6.1 - then the
two supported branches would become 1.7.x and 1.6.x, until 1.8 is
released. At our current pace of one major release every seven or eight
months (with 1.2.0/1.2.1 an anomaly), this would give a library a little
over a year of bug fixes on a given major release before they would have
to make a more significant upgrade to continue to receive bug fixes. 

Perhaps as a development community, we could commit to supporting a
major release for a minimum of 1 year if our development pace increases
and new features start rolling in? Of course, the support periods
offered by the community vs. those offered by a given support vendor can
and probably should differ. Anyways, it's just a thought, and possibly a
completely unworkable one if we were to move to a development model of
more frequent releases with smaller deltas that included the
slipstreaming of new features, rather than less frequent feature
releases with correspondingly bulkier deltas that are more likely to
introduce unexpected side-effects (the "Augh! It's the only feature
release this year, so I've got to cram in my almost-finished feature
even though it's not all that tested because otherwise I'll need to wait
until next year..." syndrome).

On the OpenSRF side, Scott has put in a massive amount of work
refactoring and optimizing the OpenSRF and Evergreen C code. I had
suggested a 1.4.0 beta of OpenSRF at our last development meeting
(http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-12:minutes) and received some support for the idea - there's OpenSRF code that hasn't seen the light of even an alpha release for 8 months now.

As for 2.0 and major infrastructure changes, part of my motivation
(personal and employment-related) is working on things that make an
immediate difference to Evergreen sites. I'm therefore trying to figure
out where to invest my time. If something isn't expected to land in a
real release until 2011 - even if it is Really Cool(TM) like in-db
ingest and kick-butt indexing & query parsing - then I'm probably going
to focus on a different problem, or attack the problem using the
currently available infrastructure, rather than worrying about something
in trunk that still might change dramatically in six months time before
it ever sees the light of day.

Thanks for opening up this discussion, Mike; I know you probably cringe
in anticipation of my response :)