[7u communication] Schedule and release renumbering update

[Andrew Hughes]

----- Original Message -----
> On 4/22/2013 2:09 PM, Andrew Hughes wrote:
> >
> > ----- Original Message -----
> > Can you explain why we can't just number the release as the number of the
> > previous
> > release plus 1, like most other projects?
> >
> > A naive person would expect 17 to be followed by 18, for example, not 21.
> 
> 
> Here's what I understand about the rationale although I wasn't involved in
> any of the thinking ...
> 
> There's become something of a convention that security update releases
> are odd numbers
> and other releases are even numbers. I'm not sure how important that is
> to the outside
> world but if two security releases happen without a release in between
> you need to
> decide if you want to break that convention.
> 
> We also had a lot of confusion arise from the need to do a few unplanned
> releases.
> Builds of 7u14 existed, bugs were marked as fixed in that release,
> reports, stats,
> etc all referred to that release but all that data is now wrong, and
> that work
> is now going to (hopefully) see the light of day in 7u40. In the
> interim, internally
> and externally people couldn't understand why a bug supposedly fixed in
> 7u14 was
> reproducible in 7u17. So leaving a very generous gap between
> non-security release numbers
> means we should not have to do the re-numbering on the fly.  Leaving
> gaps between
> planned security release numbers mean there's already a place set aside
> in case
> any unplanned release has to happen. Keeping the odd numbering convention
> for security release uses up more numbers. So that's how you end up with
> such
> inscrutable jumps in numbers.
> 
> eg :
> 7u15 was a planned security release
> 7u17 was unplanned, using a reserved number (I think)
> 7u19 was reserved just in case, but not needed
> 7u21 was a planned security release
> and so forth ...
> 

Right.  It would help if this was a little more transparent, but it makes sense now.

With IcedTea, we avoid this by using micro numbering for security releases.  So the
next feature release is always the next minor number bump and the next new Java
specification level is always the next major number bump e.g.

2.x.x - related to OpenJDK 7.
2.3.x - original u6 feature release and all subsequent security releases on top
2.4.x - next feature release (u40 now)
3.x.x - related to OpenJDK 8.

So the recent 2.3.9 release has u6's features plus the security updates from
u7, u9, u11, u13, u15, u17 and u21.

> In the future a more flexible release numbering system might make this
> less of an issue
> but lots of things like auto-update would need to be taught how to
> handle such a numbering
> system so it can't happen over-night.

I take it this "auto-update" isn't part of OpenJDK?

> 
> -phil.
> 
> 
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07