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

[Anoop Atre]

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