Here are some examples of End Of Life policy statements for open source products.

http://wiki.centos.org/About/Product
http://tomcat.apache.org/tomcat-55-eol.html
http://www.openoffice.org/development/releases/eol.html


http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule is a very nice presentation of EOS and EOL dates with definitions.

Perhaps the PMC can take up this issue and settle what they want to offer as a "warranty" to users who download a version or have a version installed and are making their upgrade and security calculations for their ERP.



Ron



On 22/09/2014 12:42 PM, Pierre Smits wrote:
Jacopo,

Your first suggestion is a bit cumbersome. If an issue affects multiple
versions and it is not fixed in all versions, why not simply keep it open
as long as the release branch it affects is in the maintenance cycle?

Your second suggestion is ambiguous.
Which part of the community are you referring to with respect to decreased
interest?
What if the installed versions amongst our user base is significant
different than you expect? We can suggest the users what to use, but it is
down to migration costs and added value of the newer version how customers
decide.

And what if there is enough interest among the non-committing contributors
to continue to support a release branch, while none of the committers is
willing to? Is the PMC going to invite these non-committing contributors to
be committers as well?

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:

Some ideas to manage this workflow in a better way:

* if a bug that affects an old release branch is not backported, when we
resolve the ticket we create a new one that is linked to the original and
has the field "affected releases" set the affected old branch; this will be
a placeholder for the ones willing to maintain the old branch
* about the end of life of release branches: when we perceive a decreasing
interest from the community to backport to an old release, we could run a
vote to decide if the community is ok to anticipate the end of life of a
release branch; the ones that vote to keep the branch alive could offer to
help in the backporting process

Jacopo





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply via email to