You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ron Wheeler <rw...@artifact-software.com> on 2014/11/05 08:35:35 UTC
Release numbers
New JEP Candidate:http://openjdk.java.net/jeps/223 has an interesting take on numbering of releases.
I believe that this is partially related to the emphasis on security in on-line services and perhaps the specialization of security functions in organizations.
It also reflects the fact that backporting of security releases is required even where there is no desire to support backporting of new functionality.
If you have a 1307.01.21 and a 1307.02.21, you know that both releases have the same security patches applied even though 1307.01.21 has no additional functionality than 1307.01.20.
It also makes it easier to identify what security patches have been applied to a particular release.
One can say that security release 20 fixes issues 5678, 5789 and 5794 (as they apply to each 1307.x release) while 21 fixes issues 5799 and 6002 (as they apply to each 13.x release).
The definition of what constitutes a security release in OFBiz will be different than in a JDK or OS.
I would suggest that any issue that would allow a user who was aware of the problem to compromise the integrity of the data or business process would qualify.
It looks like an interesting proposal and does not appear to break any build practices.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Release numbers
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 22/03/2015 17:06, Nicolas Malin a écrit :
> Thanks Jacques for this update and thanks Ron for this information.
>
> My first feeling would be to says it's good rules but why change it for 8 security corrections this last 5 years.
Yes, exactly my feeling, thanks Nicolas :) And we should not expect much in the next years...
Jacques
>
> Nicolas
>
> Le 22/03/2015 11:15, Jacques Le Roux a écrit :
>> Should we not consider this?
>>
>> Hopefully we will not have much new security issues though, the last one was fixed in 12.04.04: http://ofbiz.apache.org/download.html#vulnerabilities
>>
>> Jacques
>>
>> Le 05/11/2014 08:35, Ron Wheeler a écrit :
>>> New JEP Candidate:http://openjdk.java.net/jeps/223 has an interesting take on numbering of releases.
>>>
>>> I believe that this is partially related to the emphasis on security in on-line services and perhaps the specialization of security functions in
>>> organizations.
>>> It also reflects the fact that backporting of security releases is required even where there is no desire to support backporting of new
>>> functionality.
>>> If you have a 1307.01.21 and a 1307.02.21, you know that both releases have the same security patches applied even though 1307.01.21 has no
>>> additional functionality than 1307.01.20.
>>>
>>> It also makes it easier to identify what security patches have been applied to a particular release.
>>> One can say that security release 20 fixes issues 5678, 5789 and 5794 (as they apply to each 1307.x release) while 21 fixes issues 5799 and 6002
>>> (as they apply to each 13.x release).
>>>
>>> The definition of what constitutes a security release in OFBiz will be different than in a JDK or OS.
>>> I would suggest that any issue that would allow a user who was aware of the problem to compromise the integrity of the data or business process
>>> would qualify.
>>>
>>>
>>> It looks like an interesting proposal and does not appear to break any build practices.
>>>
>>> Ron
>>>
>>>
>
Re: Release numbers
Posted by Nicolas Malin <ni...@nereide.fr>.
Thanks Jacques for this update and thanks Ron for this information.
My first feeling would be to says it's good rules but why change it for
8 security corrections this last 5 years.
Nicolas
Le 22/03/2015 11:15, Jacques Le Roux a écrit :
> Should we not consider this?
>
> Hopefully we will not have much new security issues though, the last
> one was fixed in 12.04.04:
> http://ofbiz.apache.org/download.html#vulnerabilities
>
> Jacques
>
> Le 05/11/2014 08:35, Ron Wheeler a écrit :
>> New JEP Candidate:http://openjdk.java.net/jeps/223 has an interesting
>> take on numbering of releases.
>>
>> I believe that this is partially related to the emphasis on security
>> in on-line services and perhaps the specialization of security
>> functions in organizations.
>> It also reflects the fact that backporting of security releases is
>> required even where there is no desire to support backporting of new
>> functionality.
>> If you have a 1307.01.21 and a 1307.02.21, you know that both
>> releases have the same security patches applied even though
>> 1307.01.21 has no additional functionality than 1307.01.20.
>>
>> It also makes it easier to identify what security patches have been
>> applied to a particular release.
>> One can say that security release 20 fixes issues 5678, 5789 and 5794
>> (as they apply to each 1307.x release) while 21 fixes issues 5799 and
>> 6002 (as they apply to each 13.x release).
>>
>> The definition of what constitutes a security release in OFBiz will
>> be different than in a JDK or OS.
>> I would suggest that any issue that would allow a user who was aware
>> of the problem to compromise the integrity of the data or business
>> process would qualify.
>>
>>
>> It looks like an interesting proposal and does not appear to break
>> any build practices.
>>
>> Ron
>>
>>
Re: Release numbers
Posted by Jacques Le Roux <ja...@les7arts.com>.
Should we not consider this?
Hopefully we will not have much new security issues though, the last one was fixed in 12.04.04: http://ofbiz.apache.org/download.html#vulnerabilities
Jacques
Le 05/11/2014 08:35, Ron Wheeler a écrit :
> New JEP Candidate:http://openjdk.java.net/jeps/223 has an interesting take on numbering of releases.
>
> I believe that this is partially related to the emphasis on security in on-line services and perhaps the specialization of security functions in
> organizations.
> It also reflects the fact that backporting of security releases is required even where there is no desire to support backporting of new functionality.
> If you have a 1307.01.21 and a 1307.02.21, you know that both releases have the same security patches applied even though 1307.01.21 has no
> additional functionality than 1307.01.20.
>
> It also makes it easier to identify what security patches have been applied to a particular release.
> One can say that security release 20 fixes issues 5678, 5789 and 5794 (as they apply to each 1307.x release) while 21 fixes issues 5799 and 6002 (as
> they apply to each 13.x release).
>
> The definition of what constitutes a security release in OFBiz will be different than in a JDK or OS.
> I would suggest that any issue that would allow a user who was aware of the problem to compromise the integrity of the data or business process
> would qualify.
>
>
> It looks like an interesting proposal and does not appear to break any build practices.
>
> Ron
>
>