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<[email protected]>
Subject: Re: [OPEN-ILS-DOCUMENTATION] Official EOL Policy
To: Documentation discussion for Evergreen software
<[email protected]>
On Tue, Nov 22, 2011 at 3:30 PM, Anoop Atre<[email protected]> 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
[email protected]
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
[email protected]
http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
