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 ...
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.
-phil.
