Open Stack

Excerpts from Alex Schultz's message of 2017-03-07 12:56:17 -0700:
> 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?

The release scripts don't have permission to merge a commit, so it would
work better if that step was done manually and then the resulting SHA
can be used in the tag request.

FWIW, we used to do something very similar to this for Python projects,
and ended up dropping it because it causes extra synchronization pains
around releases. A big part of scaling up release support was making
them easier by dropping any references to version numbers in files that
have to be checked in. I'm guessing there's no way to do that for
puppet?

Doug

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