Release tags do not live on master: 3.15.2 through 3.15.6 were tagged on branch
3.15, so git describe reaches only 3.15.1 and dev builds were stamped
3.15.2.dev<n>. Besides being confusing, rpm and dpkg both rank the released
3.15.6 above that, so a dev package will not install over a released one.
Add a top-level VERSION file naming the release the branch is working toward
(4.0.0 on master) and a mkversion helper that stamps packages from it, keeping
the tag-derived value as a floor so a forgotten bump cannot go backwards.
mkversion also replaces the block copy-pasted into seven build scripts, and
makesetup no longer writes a per-package VERSION file, so the stale checked-in
confluent_common/VERSION goes with it.
We may not know where we are going, but at least bump the minor number.
Ultimately we may not be building toward that number, or that number will be used in a different branch, but it
can at least handle more cases
Rather than manually curate the VERSION, use git tags
and auto-create intermediate builds with unique identifiers.
Identify both number of commits to indicate order and the git
short rev to see which rev matches.
Markus Hilger
Jarrod Johnson
Jarrod Johnson