Personally I don't like embedding a predicted release date in the milestone. As we've seen they are subject to change. If the milestone tag is to live on master branch, I'd prefer using the date the tag is made. So the 'b#' suffix would be unique to the milestone builds? I could live with that. My main ask is that there be a machine parsable way to distinguish a milestone tag from a release tag. The easiest to parse would be a prefix. <release-prefix><year><month><build-number> <milestone-prefix><year><month><day-or-build-number-whatever-you-like> Want to see all release tags ? git tag | grep '^<release-prefix>' Want latest milestone ? git tag | grep '^<milestone-prefix>' | sort --unique | tail -n 1 On 18-12-04 05:54 PM, Dean Troyer wrote:
However i think it's better to use the tag to allow for rebuilds of a release '2018.10.0'. My only concern here is that our current git tagging convention doesn't distinguish release from milestone. I would prefer a 'r' or 'm' prefix on our git tags. For other reasons (mostly to do with the change to consume upstream OpenStack from master) I am thinking we should adjust how we implement milestones. The TSC has already talked about adjusting our release schedule, and thus the milestone schedule, to align closer to the OpenStack cadence (The release team is going to dive in to this in more detail so final proposal TBD). If we do this the following are
On Tue, Dec 4, 2018 at 12:31 PM Scott Little <scott.little@windriver.com> wrote: the changes I am anticipating:
* do not branch milestones, just tag master * follow the OpenStack process of appending a suffix to the milestone tag to identify which milestone (ie 'b1' for milestone 1, etc: NNNNb1)
The major problem with this, and why I didn't adopt it from the start, is that we are using date-based release tags rather than semantic versioning (semver, the X.Y.Z we all know and love) so the value of the next release tag can be anticipated but not certain. For example, until a short time ago we had anticipated the next release to be 2018.03, now it is more likely to be 2018.05. That makes it hard to tag a milestone in January and have it all make sense.
dt