Skip to main content
4 of 5
deleted 203 characters in body
LightCC
  • 163
  • 1
  • 6

Read the version from metadata generated at build time

One thing you can do is to read the version from your Git tags at build time. Generate the raw text or code file that is required from your release commit after it is tagged. This metadata is a build artifact, and therefore will not be stored in the repo, but is still integrated into your code, so that the code itself knows its version to report to the user, etc.

  • The advantages of this approach:
    • You have a single source of truth - the git tags
    • You are still able to access the version in your code
    • You do not need to store the version directly in the source code, so there are not merge conflicts
  • The disadvantages are:
    • You still need to resolve the version conflicts - just it happens during the tagging process rather than as a merge conflict
    • During development, you must ensure that development builds have tags in the repo or a means of generating them in the metadata, and that metadata must be regenerated for each build (or in-between official builds for development, if necessary).

To accomplish this, you will likely need to create a script to generate the version file or a value/pair entry file (JSON, etc.). As a part of your build process, run the script, then run the rest of the build.

After a build, you will have the metadata file available, so if the source is run in a script environment, it can access the version, but it will always be the old version from the last build.

For example, in the base Python Packaging module, setuptools, there is an extension available called PBR that uses this method. It autogenerates the version info from git tags, including automatically incrementing based on a rule for every commit that doesn't have a tag. It then writes the version info into an xxx.egg-info/PKG-INFO file that is a standard metadata file for Python packages. There are a functions to pull the version and other metadata info if needed in the live scripts. These files are typically included in .gitignore, so they must be regenerated as a part of a package release or running tools that generate an executable.

LightCC
  • 163
  • 1
  • 6