Changes between Version 2 and Version 3 of VersionNumbers

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

formatting

Legend:

Unmodified
Added
Removed
Modified

  • VersionNumbers

    v2 v3  
    2222== The general scheme == 
    2323 
    24 $year . $major-release . $minor-version 
     24''' ''$year'' . ''$major-release'' . ''$minor-version'' ''' 
    2525 
    26 Together, the $year and $major-release identify the major version. 
     26Together, the ''$year'' and ''$major-release'' identify the major version. 
    2727 
    28 When the $major-release is even, it's a stable release. Minor releases within a stable release are compatible. That is, programs that worked with 2010.2.0 or 2010.2.1 will still work with 2010.2.2. (Note, we have not decided if programs that work with later minor releases should also work with earlier ones, ie can minor releases add new APIs. This policy question has to be resolved by the libraries list.) 
     28When the ''$major-release'' is even, it's a stable release. Minor releases within a stable release are compatible. That is, programs that worked with 2010.2.0 or 2010.2.1 will still work with 2010.2.2. (Note, we have not decided if programs that work with later minor releases should also work with earlier ones, ie can minor releases add new APIs. This policy question has to be resolved by the libraries list.) 
    2929 
    30 When the $major-release is odd, it's a testing pre-release. Minor releases are fresh testing snapshots. There is no API compatability guarantee. 
     30When the ''$major-release'' is odd, it's a testing pre-release. Minor releases are fresh testing snapshots. There is no API compatability guarantee. 
    3131 
    3232== Rationale == 
    … …  
    3838== FAQ == 
    3939 
    40 Q: Are pre-releases API compatible with the final release? 
    41 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. 
     40'''Q:''' Are pre-releases API compatible with the final release? 
    4241 
    43 Q: Should the pre-release for 2010.2.0 be called 2010.1.x even if it's still 2009? 
    44 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. 
     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. 
    4548 
    4649== Alternatives ==