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

Tue Dec 20 16:38:45 EST 2011

Hi Kathy
I did say "Here are examples" : ) but yes there was discussion during 
the previous developer's meeting about trying to get 2.2 out in March so 
there is an expectation among at least some of the developers.

We wanted to get some community feedback on the topic and at the same 
time notify the community on what's going regarding release cycles. The 
policy implementation hasn't been hashed out fully at this time. The 
first time-based release will probably have hiccups and I wouldn't be 
surprised if it gets pushed a few weeks.

<speculation>
I don't see a RC in January (and hope to be wrong), currently the 
developers are talking about merging a list of developments into master 
before 2.2 alpha2. So best case scenario, if we get some good testing 
done in January we can hope to see a beta release by the end of January. 
I believe at beta we will feature-freeze and another set of testing 
should bring us a RC release say late February, leading to a final GA 
(General Availability) release sometime towards the end of March.
</speculation>

Maybe what we need to plan next is a release manager with a big stick?

Cheers

On 12/20/2011 02:42 PM, Kathy Lussier wrote:
> 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
>
> _______________________________________________
> 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