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

[Mike Rylander]

On Tue, Apr 6, 2010 at 4:29 PM, Dan Scott <dan at coffeecode.net> wrote:
> On Tue, 2010-04-06 at 11:25 -0400, Mike Rylander wrote:

[snip]

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

I didn't realize you were targetting 1.6.1 -- I hadn't been following
the commits closely.  Cool!

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

There's the stuff you put in, but in order to make serials work with
Acq, and make items circulate using the issuance backend that we've
been dreaming of, a ton more will be coming.  Dan Wells, expect a lot
of discussion soon on your proposed schema! (
http://open-ils.org/dokuwiki/doku.php?do=revisions&id=acq:serials:basic_predicting_and_receiving
)

IOW, I'm thinking of the
subscription/distribution/issuance/shelving-unit stuff, in addition to
the (quite excellent) MFHD functionality.

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

It /could/ be ... it depends on what can be backported, and if anyone
steps up to do the backporting (other than someone being contracted to
do it).  If the backporting were community work, and started as soon
as 1.6.1 dropped, then it would be release whenever it was done.  As
far as scheduling goes, I'm just talking about what I can directly
control and attribute in terms of resources.  And, in the case of
1.6.2, that's not much right now with 2.0 and 1.6.1 and FulfILLment
going on concurrently. ;)

But, why not call it 1.8?  Because then we'd be releasing 1.8 (a big
conceptual jump from 1.6) after (or nearly coincident with) 2.0, which
seems stranger to me than extending 1.6 as an existing stream by
adding new features from a forward branch.  From a maintenance
perspective, it would mean three open major revision (2.0, 1.8, 1.6)
branches instead of two (2.0, 1.6).  While, by all accounts, almost
everyone that is considering Evergreen but not yet using it is indeed
waiting on what will be in 2.0, there are plenty of current users for
whom 1.6.something-or-other will be viable for the foreseeable future.

More generally, while I'm thinking about it (and you touch on it
below), we haven't discussed EOLing release streams outright ... they
just kind of die.  I think we should state a general policy, and I
would propose that policy to be something like:

  We will make every effort to maintain bug fix releases for the
highest minor revision on the newest major revision, until that stream
is no longer the immediately previous major revision.

Clear as mud, right?  For example, if a major bug was discovered in
1.4.0 today, and a fix was both reasonable to implement in terms of
effort /and/ safer for most 1.4 users than the risk of upgrading to
1.6.0.newest, then I'd be in favor of creating a bugfix release
(1.4.0.8).  However, as soon as 2.0 is cut, 1.4 is dead (just like 1.2
is dead (by attrition and convention) now that 1.6 is out).  But that
doesn't mean that we couldn't (if there were a strong reason to)
release 1.4.1.0 right now.  Then 1.4.0 would be dead, and 1.4.1 would
be the branch to receive bug fixes.

Because the jump from 1.6 to 2.0 will be so huge, and a great deal of
the code in 2.0 will be immature at the start of the 2.0 stream, it
seems reasonable to me to expect many users to want to stay on 1.6 for
a while.  If some features present themselves as good backporting
candidates then we should make an effort to extend 1.6.  My proposed
list is entirely hypothetical, of course, but just what I see right
now.  Serials beyond straight MFHD may well be untenable to backport,
but A/T enhancements probably aren't, for instance, and for users of
1.6 today that would be a big win.  (And as a side note, if we want to
get 1.6.1 out, which I certainly do, then anything not in cleanup mode
today needs to wait.)

> 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

To be fair, the Booking Reservation work is probably bigger than any
two in combination of the above mentioned three possibilities.  It's
"just one feature" but the impact on the code is very broad.

> , 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 :)
>

Well, to be frank, I think we /should/ continue using that scheme*.
It provides a clear frame of reference (at least to me) about what can
go where, and when.  The way I describe the scheme is:
{world-altering-changes}.{requires-a-new-staff-client-changes}.{new-minor-feature-changes}.{bug-fixes}.
 To put more traditional labels on the components:
{version}.{major-revision}.{minor-revision}.{release}

But that's not my reasoning -- I consider the naming scheme a feature.
 My reasoning is just up ^ there.


* Now, all that being said, if someone were to take on the project of
actually setting up a CI system (ESI would be happy to host the
buildbot again or toss up a server for something else, but, as time
and resources stand now, bootstrapping that is something that others
will need to put some muscle behind) then I'd be happy to toss version
numbers out the window and start stamping test-passing,
consensus-gaining nightly builds as releases as soon as they're ready,
as we discussed last year.

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

I agree with that worry ... that's why I'm (tangentially) proposing a
general EOLing rule of supporting, from a community perspective, the
newest minor revision of the immediately previous major revision for
any bug fixes.  That leaves us, effectively, where we are today.  We
have trunk, rel_1_6, rel_1_6_X (soon to move from 0 to 1), and for
severe data-loss bugs, rel_1_4_{newest}.  When 2.0 is released we'll
have trunk, rel_2_0, rel_2_0_0 and rel_1_6_{newest}.

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

You mean 1.6.1, I assume.

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

I think we're trying to get to basically the same place, we just seem
to disagree on the utility of the 4-number scheme.

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

Another vote for 1.6.2, IMO. ;)

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

I'm all for someone picking up the release torch, particularly for
OpenSRF.  OpenSRF is super-easy to cut a release for, especially
compared to Evergreen, and I'd support getting the code out there,
too.  I just don't have the time until I'm pressed by an Evergreen
dependency.

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

To me, that's even more reason to consider a 1.6.2 release targetting
some trunk features that could be (relatively easily) backported and
get to see the light of day sooner.  IMO, /that/ would be a great
place to focus in order to make an immediate difference.  If someone
were to pull, say, A/T enhancements and telephony from trunk into 1.6
after 1.6.1 dropped, I'd consider that enough to warrant a 1.6.2,
personally.

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

Your examples will be in the 2.0 alpha targetting August 2010
(twenty-ten, no typo) which will come from trunk.  It'll be in use by
at least one site come this September.  There will be plenty of work
to do to call it 2.0.0.0, but it will be based on real-world use of
the system.  But, even then, if you're basing new features off of 1.6
that require integration with infrastructure that is new, enhanced or
replaced in trunk, forward-porting will probably be harder than
backporting in most cases, and just as hard in the others.  See Also:
Booking ... :(

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

Cringe isn't the right word ... ;)

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com