[Starlingx-discuss] [Container] Public docker registry

[Dean Troyer]

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