OK I began this convo. Inline...
Le 22/09/2014 21:15, Jacopo Cappellato a écrit :
We are maintaining somewhat similar information in these pages:
http://ofbiz.apache.org/download.html
This is where we should be more specific and explain things better as I kinda
suggested in one of my message http://markmail.org/message/pos2gnyj47uxsn5s
Excerpts:
<<the problem is not everybody is aware of bug fixes backported or not. The
official download page http://ofbiz.apache.org/download.html, says that we
stabilize releases with bug fixes. It's not quite clear if we are backporting all or
only some bug fixes.>>
<<I think we should make that clear and expose a way to users for them to more
"easily" maintain the releases they use.>>
As suggested Ron we could also define our own or refer to
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Now we need to think "technical" and automatize as possible with Jira
What I have read so far from Jacopo seems a good start to me
Jacques
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
