[OPEN-ILS-DEV] Like sugarplums, but they can't dance as well

[Dan Scott]

Hi Robert:

On 3 January 2011 14:53, Soulliere, Robert
<robert.soulliere at mohawkcollege.ca> wrote:
> Hi all,
>
> I created installation instructions for 1.6.2:
> http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.6.2:install
>
> and upgrading instructions:
> http://evergreen-ils.org/dokuwiki/doku.php?id=upgrading:evergreen:1.6.1.5_to_1.6.2.0
>
> I don't think I have access to edit tine downloads page itself?

You can submit a patch against the downloads.php page at
svn://svn.open-ils.org/ILS-Contrib/evergreen-ils.org
(http://svn.open-ils.org/trac/ILS-Contrib/browser/evergreen-ils.org);
currently Jason Etheridge and myself have access to write to this
repository, so a patch posted to open-ils-dev is probably the best
option. But, before you do that...

> Upgrading instructions in official documentation also updated to reflect 1.6.2 as latest version:
> http://docs.evergreen-ils.org/1.6/draft/html/upgradingevergreen.html

Thanks for all of this work, but... one of the reasons I didn't do any
of this is because:

1) Almost all of the development team's focus has been on 2.0. The
1.6.2.0 release is not particularly well-tested (out of the box, for
example, there's a bug that I was responsible for which prevents you
from editing MARC records; I've fixed that now, but will need to wait
for a 1.6.2.1 release, and there's no guarantee that other similar
major bugs aren't lurking just below the surface).*

2) There's no upgrade path planned for getting from 1.6.2.0 to 2.0.0;
enough database schema changes were backported from 2.0 that trying to
support both a 1.6.1 -> 2.0.0 upgrade path and a 1.6.2 -> 2.0.0
upgrade path would be overwhelming, so the planned upgrade path will
be from 1.6.2 -> 2.1.0.

3) Given #1 and #2, we don't really want to encourage sites to migrate
to 1.6.2.0; we would rather that sites that want to move on past
1.6.1.x join in to help test 2.0 and go directly to 2.0 as the best
option all around, or otherwise sit on the much more stable 1.6.1.x
series.

4) Given the draft supported releases policy
(http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:supported_releases),
per policy we should be dropping support for 1.6.1.x and only
supporting 1.6.2.x and 1.4.0.x until 2.0.0 comes out, at which point
the supported releases would be 2.0.x and 1.6.2.x - but given #3, we
really don't want to encourage adoption of 1.6.2.x. (Not surprisingly,
the request for comments on the draft "supported releases" policy that
I sent out on December 21st hasn't had much commentary yet so we're
still listing 1.6.1.x, 1.6.0.x, and 1.4.0.x as the supported releases
on the downloads page).

So... given #1 through #4, why does the 1.6.2.0 release exist at all?
The answer is that Equinox had a contractual obligation to create a
1.6.2.0 release; however, contracts with individual Evergreen
communities can't determine what the Evergreen community as a whole
supports or recommends for use in production.

Ergo - I'm not sure we even want to advertise the 1.6.2.0 release, in
any way. I'm sorry if this means that you've wasted your time; but if
this comes as a surprise to anyone else (I'm sure it does to you),
note that almost all of this has been discussed during the Evergreen
developer team meetings (see
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2010-12-07
and the raw IRC logs for the meeting at
http://evergreen-ils.org/irc_logs/evergreen/2010-12/%23evergreen.07-Tue-2010.log
as a reasonable starting point for the official discussion about the
status of 1.6.2.0).

* Aside: To prevent similar egregious errors in future releases, I'm
hoping that James Fournie's stub page for QA test cases
(http://evergreen-ils.org/dokuwiki/doku.php?id=qa:eg_test_cases) gets
fleshed out into something more like Mozilla's litmus
(https://litmus.mozilla.org/) and adopted in the "release checklist"
(http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:release_checklist)
as part of the process of rolling out a release. Of course, if I was a
better developer then the problem would never have been introduced,
but back when I committed that code to rel_1_6 there was no
expectation of creating a 1.6.2.x release... so I didn't put in the
level of QA that I normally would.