Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Kinds of Tags

There are two kinds of tags...

  • Next version base tags, which have an "r" suffix. Example, "1.8.0r".
  • Final, shipped release tags. Example, "1.8.0".

Applying the Tags

How and when do we use those kinds of tags?

Let's follow an example, where we're working towards shipping 1.8.0, then we ship 1.8.0, and then we start working on the next release of 1.8.1...

  1. When we start working on a new release like 1.8.0, across its relevant components, we tag one of its commits (ideally, the first new commit meant for 1.8.0) with a next version base tag. In this case, we tag with "1.8.0r".
    • If there's no commits yet for a component for 1.8.0, perhaps because the component is rather stable and slowly changing, we can choose to either make a trivial change/commit, or just not tag the component with "1.8.0r" until later.
  2. Builds during the development cycle will look like 1.8.0r-57-g238485a. That is, "$(TAG)$(GIT_CHANGE_NUM)$(GIT_UNIQUE_HASH)".
    • The GIT_CHANGE_NUM increments with each build.
    • The GIT_UNIQUE_HASH uniquely identifies the build.
  3. We eventually release and ship the final, blessed version, such as 1.8.0r-117-g43211234.
  4. After shipping, we tag 1.8.0's relevant components with the final, shipped release tag of "1.8.0" for the historical record.
  5. Next, we start working towards shipping 1.8.1 and repeat the cycle.
    • That is, new commits meant for 1.8.1 are created by developers and submitted.
    • We tag one of those new commits meant for 1.8.1 with a next version base tag. In this case, "1.8.1r".

Use Annotated Tags

Taggers, be sure to use annotated tags (the -a flag when creating a git tag). For example...

git tag -a 1.8.0 -m 1.8.0
git push --tags origin

What and What Not To Tag

The set of component repositories that need tagging in a release are listed in the release-specific manifest XML files: https://github.com/membase/manifest

However, some components have their own versioning "namespace" and are often coming from pre-existing open-source community projects; and we do not tag them during our product releases. These include....

  • couchdb
  • memcached
  • memcachetest
  • libmemcached
  • sigar

Other external dependencies, such as those listed in the external/override XML files, (obviously) also should not be tagged during our product releases. These include...

  • otp
  • icu4c
  • spidermonkey
  • libevent
  • curl

Release Candidates / Developer Previews

We no longer create tags for release candidates or rc's, or developer previews. Instead, we externally remember that "2.0.0r-21-g12345435" == "2.0.0r dev preview 1".

1.7.2r-20 == 1.7.2 release

1.8.0r-55 == 1.8.0 release

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.