On Tue, Dec 4, 2018 at 12:31 PM Scott Little <scott.little@windriver.com> 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 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 -- Dean Troyer dtroyer@gmail.com