Open Stack

Excerpts from Alex Schultz's message of 2017-03-09 11:29:28 -0700:
> On Thu, Mar 9, 2017 at 10:54 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> > 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.
> >
> 
> Ok then I guess as part of release prep we can just handle the
> dropping of the -dev.  Would it be possible for the release process to
> at least propose the next '-dev' version via the release tools?

That seems like a reasonable thing to add.  The natural way to do
it is to add a new job to the tag pipeline for the repositories.
You'll likely want to copy some of the configuration from the
tag-releases job, because that runs on a node with permission to
propose new patches.

> > 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?
> >
> 
> No because the metadata.json is the source of truth for the version
> information for the puppet modules so it either has to either exist or
> be generated and committed so that when people checkout from git
> puppet knows what versions are there.  Technically if you're only

Yes, that's what I was afraid of.

> doing source deployments you could manage the versions yourself and
> just ignore the warnings from puppet but it also makes it hard to know
> what your environment has version why.  'puppet module list' pulls the
> version information out of the metadata.json.  If we automate (and
> document) some of this workflow it's not so bad as we've been handling
> all this version mangling already.
> 
> for module in $list; do
> pushd $module; sed -ie 's/-dev//' metadata.json; git add
> metadata.json; git commit -m "release prep"; git review; popd
> done
> 
> Thanks,
> -Alex
> 
> > Doug
> >
> >>
> >> Thanks,
> >> -Alex
> >>
> >> [0] https://bugs.launchpad.net/tripleo/+bug/1669462
> >> [1] https://github.com/puppetlabs/puppet/blob/master/lib/semver.rb#L10
> >>
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>