[7u communication] Schedule and release renumbering update
philip.race at oracle.com
Tue Apr 23 12:49:19 PDT 2013
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
Builds of 7u14 existed, bugs were marked as fixed in that release,
etc all referred to that release but all that data is now wrong, and
is now going to (hopefully) see the light of day in 7u40. In the
and externally people couldn't understand why a bug supposedly fixed in
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
planned security release numbers mean there's already a place set aside
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
inscrutable jumps in numbers.
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 ...
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.
More information about the jdk7u-dev