Open Stack

Ahoy folks,

I would like to bring attention to deriving version numbers for puppet
modules (for packaging) as part of the release process.  Today we
uncovered an issue[0] in the way that version numbers were being
derived for packages which ultimately broke the TripleO CI upgrade
jobs because the master version was older than the last released Ocata
version.

As for a bit of history around the puppet version numbers, PEP-440 is
not supported in puppet and they are using a form of SemVer[1] .  So
we've historically chosen to just use X.Y.Z for our version numbers
and we usually end up bumping them prior to cutting a new release.
That being said, for the first time we've run into the issue where the
master branches metadata.json contained a version less than the
stable/ocata branch which resulted in the upgrade jobs failing.

In this case, we could have avoided the version issue by pushing a
version bump to master after cutting the stable/ocata branch to ensure
that master would be the next version.  We've talked about improving
the automation around the puppet versions in the past and I'm
wondering if this is something that would be best to be done in the
release process.  Now because puppet supports SemVer, we could
designate the next version as a X.Y.Z-dev version in the metadata.json
and would expect packagers to use the metadata.json file as the source
of truth for deriving version information and not using something like
pbr or git describe.  Right now as it sits for puppet modules, we
generally aren't touching the version information until we're ready to
release the next version which doesn't seem right for knowing what the
current version of the code actually is.

So what I'm proposing is to use a "-dev" pre-release identifier
between version releases for puppet modules.  As part of the tagging
process we could propose the next release version with "-dev" to the
repository.  The flow would look something like...

MASTER
1.0.0-dev
   +
   |     TAG: M1
   +---> 1.0.0
   |
   v
MASTER
1.1.0-dev
   +
   |     TAG: M2
   +---> 1.1.0
   |
   v
MASTER
1.2.0-dev
   +
   |     TAG: M3
   +---> 1.2.0
   |
   v
MASTER
1.3.0-dev
   +
   |     TAG: RC1
   +---> 1.3.0
   |
   v
RELEASE
   +
   |     STABLE BRANCH
   +---> 1.4.0-dev
   |
   v
MASTER
2.0.0-dev

Currently since the metadata.json file is in the repository and for
the release process we're providing a git hash for the version to tag,
I'm not sure how the dropping of the "-dev" would work.  Since we
basically want the release process to take the hash, mangle the
metadata.json, commit it and use this new hash as the point to tag.
thoughts?

Thanks,
-Alex

[0] https://bugs.launchpad.net/tripleo/+bug/1669462
[1] https://github.com/puppetlabs/puppet/blob/master/lib/semver.rb#L10