Changes between Version 3 and Version 4 of VersionNumbers

Show
Ignore:
Timestamp:
04/30/09 14:39:09 (4 years ago)
Author:
duncan (IP: 79.70.231.184)
Comment:

add FAQ about year as part of the major version

Legend:

Unmodified
Added
Removed
Modified

  • VersionNumbers

    v3 v4  
    3636We 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. 
    3737 
    38 == FAQ == 
    39  
    40 '''Q:''' Are pre-releases API compatible with the final release? 
    41  
    42 '''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. 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. 
    43  
    44  
    45 '''Q:''' Should the pre-release for 2010.2.0 be called 2010.1.x even if it's still 2009? 
    46  
    47 '''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. 
    48  
    4938== Alternatives == 
    5039 
    5140One 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. 
     41 
     42== FAQ == 
     43 
     44 * '''Q:''' Are pre-releases API compatible with the final release? 
     45 
     46   '''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. 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. 
     47 
     48 * '''Q:''' Should the pre-release for 2010.2.0 be called 2010.1.x even if it's still 2009? 
     49 
     50   '''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. 
     51 
     52 * '''Q:''' Why not use a monitonically increasing major version number? Why use the year? 
     53 
     54   '''A:''' Because it makes it clear that it is a never a finished project, and that we do time-based rather than feature based releases. It also tells you slightly more information (e.g. you can quickly tell how out-of-date your distro's support is).