Re: Release Strategy and Branch Support

[Ron Wheeler <rw...@artifact-software.com>]

Yes and we have started to update those pages.

What is missing that the other projects include, are statements about 
the intended end of the periods during which users can expect new 
features to be added and when there will only be security/severe bug 
fixed and when the version will be officially retired and no code 
changes by the team.


Ron

On 22/09/2014 3:15 PM, Jacopo Cappellato wrote:
> 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 <rw...@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.cappellato@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: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>


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