|Version 1 (modified by duncan, 5 years ago)|
Platform version numbers
This page describes how the version numbers for the platform work and why we do it this way.
These are the important points to keep in mind when considering schemes for version numbers:
- We have two major releases per year
- Minor releases are API compatible
- We have testing pre-releases for each major release
- 2010.1.0, 2010.1.1, ... testing pre-releases for the first major release of the year
- 2010.2.0: first major release in 2010.
- 2010.2.1: minor bug fix release, compatible with 2010.2.0
- 2010.3.0, 2010.3.1, ... testing pre-releases for the second major release
- 2010.4.0: second major release in 2010.
- 2010.4.1: minor bug fix release, compatible with 2010.4.0
We need to be able to distinguish major from minor releases. So we cannot simply use the date.
We need to give version numbers to pre-releases because we need to get wide testing from developers/users, so being able to track and identify pre-releases is important.
Q: Are pre-releases API compatible with the final release? A: No, there is no such guarantee for testing pre-releases. Only minor stable releases are guaranteed to be API compatible with the previous minor releases in the same major release series. That is, programs that worked with 2010.2.0 or 2010.2.1 will still work with 2010.2.2. In practice we expect there to be an API freese some weeks before the major release, so that testers have time to check the whole thing works without there being constant API churn.
Q: Should the pre-release for 2010.2.0 be called 2010.1.x even if it's still 2009? A: Yes, the current date does not matter. It's the target release date that matters. It should be called 2010.1.x, not something like 2009.5.x.
One alternative that fits the requirements is a monitonically increasing major version number, like 20.x for a major release and 20.0, 20.1, etc for minor releases. This is what GNOME uses.