We are maintaining somewhat similar information in these pages: http://ofbiz.apache.org/download.html http://www.apache.org/dist/ofbiz/
Jacopo On Sep 22, 2014, at 8:31 PM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > 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 >
