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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev