Skip to content
  • Brad King's avatar
    New version scheme to support branchy workflow · 5bfffd6f
    Brad King authored
    Prepare to switch to the workflow described by "git help workflows".  In
    this workflow, the "master" branch is always used to integrate topics
    ready for release.  Brand new work merges into a "next" branch instead.
    We need a new versioning scheme to work this way because the version on
    "master" must always increase.
    
    We no longer use an even/odd minor number to distinguish releases from
    development versions.  Since we still support cvs checkout of our source
    tree we cannot depend on "git describe" to compute a version number
    based on the history graph.  We can use the CCYYMMDD nightly date stamp
    to get a monotonically increasing version component.
    
    The new version format is "major.minor.patch.(tweak|date)".  Releases
    use a tweak level in the half-open range [0,20000000), which is smaller
    than any current or future date.  For tweak=0 we do not show the tweak
    component, leaving the format "major.minor.patch" for most releases.
    Development versions use date=CCYYMMDD for the tweak level.  The
    major.minor.patch part of development versions on "master" always
    matches the most recent release.
    
    For example, a first-parent traversal of "master" might see
    
            v2.8.1      2.8.1.20100422    v2.8.2
               |              |              |
      ----o----o----o----o----o----o----o----o----
    
    Since the date appears in the tweak component, the next release can
    increment the patch level (or any more significant component) to be
    greater than any version leading to it.  Topic branches not ready for
    release are published only on "next" so we know that all versions on
    master lead between two releases.
    5bfffd6f