[Starlingx-discuss] [Container] Public docker registry

[Scott Little]

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:
> 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
>