[7u communication] Schedule and release renumbering update

[Phil Race]

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.