-----Original Message-----
From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-
dev-boun...@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<d...@coffeecode.net>
Subject: Re: [OPEN-ILS-DOCUMENTATION] Official EOL Policy
To: Documentation discussion for Evergreen software
<open-ils-documentat...@list.georgialibraries.org>
On Tue, Nov 22, 2011 at 3:30 PM, Anoop Atre<anoop.a...@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-documentat...@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
