Hi Robert: On 3 January 2011 14:53, Soulliere, Robert <[email protected]> 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.
