[OPEN-ILS-GENERAL] [OPEN-ILS-DEV] [OPEN-ILS-DOCUMENTATION] Official EOL Policy

Kathy Lussier klussier at masslnc.org
Tue Dec 20 15:42:52 EST 2011


Thanks for forwarding this along Anoop! I think the time-based releases will
be very helpful as institutions plan their upgrades, and a 15-month support
cycle seems reasonable. In general, I would say this is a positive move
forward.

I do have questions regarding this next release of 2.2 that, according to
the policy, would be coming out in March. I don't know that anyone has
answers to these questions yet, but I'm curious as to when certain steps
need to be taken to get to a full release in March. In looking at the
release schedule for 2.1, beta was released on May 5, 2011 and 2.1.0 was
released five months later in early October. Looking at the logs from
today's developer's meeting, it looks like an alpha2 release for 2.2 is in
the works for the beginning of the new year. Is there an expectation that
the 2.2 release cycle will be faster than the one for 2.1? To get to a March
release, what is the drop dead date for getting a 2.2 beta and a subsequent
release candidate?

In the spirit of full disclosure, there is a bit of self interest in my
questions as there is a MassLNC consortium that needs functionality
available in 2.2 (some of which was merged into master way back in early
July) before going live on Evergreen. We would love to see a release
candidate for 2.2 in January, and, given the schedules I've seen for past
release, it seems like this would need to happen fairly soon if a full
release were to come out in March.

Thanks!
Kathy Lussier

-------------------------------------------------------------
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 756-0172
(508) 755-3721 (fax)
klussier at masslnc.org
IM: kmlussier (AOL & Yahoo)
Twitter: http://www.twitter.com/kmlussier
 
 

>>-----Original Message-----
>>From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-
>>dev-bounces at list.georgialibraries.org] On Behalf Of Anoop Atre
>>Sent: Tuesday, December 20, 2011 12:04 PM
>>To: Documentation discussion for Evergreen software; Evergreen
>>Discussion Group; Evergreen Development Discussion List
>>Cc: Ben Hyman
>>Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-DOCUMENTATION] Official EOL
>>Policy
>>
>>Based on Ben's suggestion and discussion during the last developer's
>>meeting here is the revised release & EOL policy proposal:
>>
>>"Time based releases occur every 6 months with each release getting 15
>>months of support (12 for general bugs and 3 more for security)."
>>
>>The current proposal is to release in March and September since this
>>works best for public libraries and at the same time gives
>>academic/government institutions extra time to plan summer upgrades.
>>This should also allow the community to expect a more predictable
>>release cycle.
>>
>>Here are examples on how the revised policy translates:
>>
>>* Evergreen 2.2 will be released in March 2012, general bug support
>>will
>>be provided till March 2013 and security bugs/issues will be  supported
>>for a further 3 months i.e. June 2013.
>>
>>* Evergreen 2.3 gets released in September 2012 and supported till
>>September 2013 for general bugs plus another three months for security
>>issues so December 2013
>>
>>* Evergreen 2.4 is released in March 2013 at which time an announcement
>>regarding the expected EOL of 2.2 in June 2013 is sent out. Evergreen
>>2.4 will be supported through March 2014 (general bugs) & June 2014
>>(security bugs).
>>
>>---
>>
>>Please respond if this sounds like an acceptable policy OR if there are
>>more thoughts/concerns about the time based release proposal, the
>>months
>>of the releases or support lengths.
>>
>>Cheers
>>
>>On 12/03/2011 11:49 AM, Ben Hyman wrote:
>>>> Date: Fri, 2 Dec 2011 13:40:26 -0500
>>>> From: Dan Scott<dan at coffeecode.net>
>>>> Subject: Re: [OPEN-ILS-DOCUMENTATION] Official EOL Policy
>>>> To: Documentation discussion for Evergreen software
>>>> 	<open-ils-documentation at list.georgialibraries.org>
>>>>
>>>> On Tue, Nov 22, 2011 at 3:30 PM, Anoop Atre<anoop.atre at mnsu.edu>
>>wrote:
>>>>> At today's developer meeting there was some discussion on adopting
>>an
>>>>> official EOL policy, while there was agreement on the time frame we
>>had some
>>>>> disagreement on the wording. So this mail is to decide on the
>>wording of the
>>>>> official EOL policy for Evergreen releases.
>>>>>
>>>>> The final version of the policy that came out of the meeting which
>>we can
>>>>> start with is as follows:
>>>>>
>>>>> "The community will strive to provide support (bug fixes, updates,
>>>>> documentation, etc) for a given release series until one month
>>after two
>>>>> subsequent stable release series have been made available."
>>>>>
>>>>> Dan Scott mentioned that his would be acceptable as long as the
>>versioning
>>>>> page[1] includes a definition of "release series" and uses the same
>>>>> terminology (consistency).
>>>>>
>>>>> So the above policy translates into:
>>>>>
>>>>> * Evergreen 2.0 release series would be maintained until 1 month
>>after the
>>>>> release of the Evergreen 2.2 series.
>>>>>
>>>>> * Evergreen 2.1 would be maintained until 1 month after the release
>>of the
>>>>> Evergreen 2.3 series.
>>>>>
>>>>> So at any given time the community will be supporting two release
>>series of
>>>>> Evergreen, excluding the one month overlap where there will be
>>three
>>>>> versions supported.
>>>>>
>>>>> Aside from the wording I would propose that we send out a reminder
>>>>> announcement about the EOL when the final beta version of the
>>latest release
>>>>> series is made available so folks can start testing their system
>>upgrades
>>>>> and are not caught off guard. (add task to release team list)
>>>>>
>>>>> Please respond with a vote on the current wording of the policy or
>>with your
>>>>> version of the policy/thoughts.
>>>>
>>>> +1
>>>
>>>
>>> +1, with a friendly amendment: that a six month release cycle be
>>enshrined (meaning that any given release would be supported for one
>>year) to ensure known targets that enable sufficient planning cycles
>>across the entire community.
>>> If acceptable, this piece may best be captured on the versioning
>>page, along with the clarifications Dan Scott initially proposed.
>>>
>>> W are generally supportive of any efforts that result in the rapid
>>development of Evergreen, and also understand the challenges that
>>multiple versions create for support and development cycles.
>>> Our friendly amendment is an attempt to balance those considerations
>>against the realities facing many community members, including any
>>larger Evergreen consortia.
>>>
>>> Hand in hand with this policy, we're hopeful for a renewed
>>conversation in the new year about QA Team and DIG cycles that
>>correspond with general releases. We are currently examining our own
>>capacity to contribute more in this regard.
>>> Each new release is a tremendous milestone, and something the entire
>>community celebrates. Expectations couldn't be higher. We believe
>>enhanced QA and DIG cycles will best enable the community to track more
>>quickly through releases.
>>>
>>> Thanks for pulling this draft policy together.
>>>
>>> _______________________________________________
>>> OPEN-ILS-DOCUMENTATION mailing list
>>> OPEN-ILS-DOCUMENTATION at list.georgialibraries.org
>>> http://list.georgialibraries.org/mailman/listinfo/open-ils-
>>documentation
>>
>>
>>--
>>
>>Anoop Atre
>>IS Developer & Integrator, PALS
>>PH: 507.389.5060
>>OF: 3022 Memorial Library (Office-ML 3022)
>>--
>>"Mit der Dummheit kämpfen Götter selbst vergebens"
>>  ~ Johann Christoph Friedrich von Schiller



More information about the Open-ils-general mailing list