Proposal: mandatory versioning metadata for modules
David Jorm
djorm at redhat.com
Sun Nov 4 21:30:56 PST 2012
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-(
More information about the jigsaw-dev
mailing list