Changes between Version 8 and Version 9 of VersionNumbers

Show
Ignore:
Timestamp:
06/01/09 10:31:20 (4 years ago)
Author:
duncan (IP: 79.70.221.212)
Comment:

update to PVP versioning

Legend:

Unmodified
Added
Removed
Modified

  • VersionNumbers

    v8 v9  
    1919 * 2010.1.0, 2010.1.1, ... testing pre-releases for the first major release of the year 
    2020 
    21  * 2010.2.0: first major release in 2010. 
    22  * 2010.2.1: minor bug fix release, compatible with 2010.2.0 
     21 * 2010.2.0.0: first major release in 2010. 
     22 * 2010.2.0.1: minor bug fix release, compatible with 2010.2.0.0 
    2323 
    2424 * 2010.3.0, 2010.3.1, ... testing pre-releases for the second major release 
    2525 
    26  * 2010.4.0: second major release in 2010. 
    27  * 2010.4.1: minor bug fix release, compatible with 2010.4.0 
     26 * 2010.4.0.0: second major release in 2010. 
     27 * 2010.4.0.1: minor bug fix release, compatible with 2010.4.0.0 
    2828 
    2929== The general scheme == 
    3030 
    31 ''' ''$year'' . ''$major-release'' . ''$minor-version'' ''' 
     31''' ''$year'' . ''$major-release'' . 0 .  ''$minor-version'' ''' 
    3232 
    3333Together, the ''$year'' and ''$major-release'' identify the major version. 
    … …  
    4343We 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. 
    4444 
     45The version scheme should follow the PVP and should reflect the fact that it is the union of its components. Since minor releases may not change API at all then this dictates that only the 4th digit changes. The 3rd digit remains at 0 because there are never any API-compatible additions in a minor release. 
     46 
    4547== Alternatives == 
    4648 
    4749One 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. 
    48  
    49 It has been suggested that the platform version numbers follow the [http://www.haskell.org/haskellwiki/Package_versioning_policy PVP] in the sense that the platform is the union of all it's components. In this case, if we agreed that there are no API changes in minor releases then the general scheme would be ''' ''$year'' . ''$major-release'' . 0 . ''$minor-version'' '''. That is, the 3rd digit would always be zero. This would be because major releases typically have some slight incompatible change in at least one package while minor releases do not change any API at all, only fix bugs, so only the 4th digit changes. 
    5050 
    5151== FAQ ==