Proposal: mandatory versioning metadata for modules

[David Jorm]

On 11/05/2012 01:00 AM, Florian Weimer wrote:
> * Alan Bateman:
>
>> On 04/11/2012 12:01, Florian Weimer wrote:
>>> * David Jorm:
>>>
>>>> The problem here is "optional" version number. What I'm trying to
>>>> achieve is mandatory minimal version metadata.
>>> I don't think we'll change version numbers in security updates (just
>>> like we don't change sonames and other identifiers), so I'm not
>>> convinced this will work.

Generally speaking, security issues in java components are fixed in new 
revisions of components, rather than as some kind of one-off patch that 
is de-coupled from the revision number. Even when a fix is isolated, the 
new release including that isolated fix often has a new revision. A good 
example is Spring 2.5.6, which had several security issues that resulted 
in 2.5.6.SEC01, 2.5.6.SEC02 and 2.5.6.SEC03 releases.

>> Who is "we"?
> Anyone in the FLOSS world who releases security updates for stable
> release branches.  Unless a new upstream release is imported, such
> updates will not change the version number reported by the software.
> (Only the external version number for the packaging tool is upgraded.)

To my knowledge, most FLOSS vendors only maintain stable release 
branches for a small number of java components. Most of the broader set 
of components is built directly from upstream versions, and upstream 
usually provides fixes in a new revision. Of course there are 
exceptions, but this is the case for the instances I am aware of.

David

>> At least for the JDK then the version number is rev'ed at
>> each update, including security updates.
> And I suspect that there is code out there which checks the version
> string and refuses to run. 8-(