> 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
