Changes between Version 9 and Version 10 of VersionNumbers

Show
Ignore:
Timestamp:
06/01/09 18:06:59 (5 years ago)
Author:
duncan (IP: 129.67.151.47)
Comment:

finish updates to reflect the PVP policy decision

Legend:

Unmodified
Added
Removed
Modified
  • VersionNumbers

    v9 v10  
    77  * Minor releases are API compatible 
    88  * We have testing pre-releases for each major release 
    9   * The Haskell [http://www.haskell.org/haskellwiki/Package_versioning_policy Package Versioning Policy] 
     9  * We follow the Haskell [http://www.haskell.org/haskellwiki/Package_versioning_policy Package Versioning Policy] (PVP) 
    1010 
    1111The Haskell Platform concept calls for major and minor releases. 
     
    1414 
    1515 * The point of minor releases is to support a major release across a range of operating systems over time and respond to bugs that are discovered in a library or tool subsequent to their release. The target is to have 2-3 minor releases after major releases at intervals on the order of 4-6 weeks. 
     16 
     17The [wiki:Policy policy decision] agreed on the libraries mailing list is that minor (or patch-level) release must not change the exported API of any library packages and that the platform as a whole must follow the PVP. 
    1618 
    1719== Examples == 
     
    2729 * 2010.4.0.1: minor bug fix release, compatible with 2010.4.0.0 
    2830 
    29 == The general scheme == 
     31== The general scheme for stable releases == 
    3032 
    3133''' ''$year'' . ''$major-release'' . 0 .  ''$minor-version'' ''' 
     
    3335Together, the ''$year'' and ''$major-release'' identify the major version. 
    3436 
    35 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.) 
     37When the ''$major-release'' is even, it's a stable release. Minor (or patch-level) releases within a stable release have exactly the same API. Only bug fixes are allowed in patch-level releases. 
    3638 
    37 When the ''$major-release'' is odd, it's a testing pre-release. Minor releases are fresh testing snapshots. There is no API compatability guarantee. 
     39When the ''$major-release'' is odd, it's a testing pre-release. Minor releases are fresh testing snapshots. There is no API compatibility guarantee. 
    3840 
    3941== Rationale == 
     
    6264 
    6365   '''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). 
     66 
     67 * '''Q:''' Why is there a redundant 0 as the third digit? 
     68 
     69   '''A:''' Because that is what is required for the platform to follow the Package Versioning Policy (PVP). Since minor releases do not  change the API at all, then the PVP dictates that we bump the 4th digit, not the 3rd. The 3rd is reserved for compatible API additions. 
     70 
     71 * '''Q:''' Why did the first 2009.2.0 release not use a 4th digit like 2009.2.0.0? 
     72 
     73   '''A:''' Because the decision to follow the PVP was made after 2009.2.0 had already been released.