Tagging master

[Joel Stanley]

On Wed, 22 Aug 2018 at 23:37, Patrick Venture <venture at google.com> wrote:
> > > So this would be a non-versioned tag?  I believe we already have
> > > versions that are meant to track behind or with yocto (once the
> > > release schedule hits).  Since these aren't tested, I'd suggest they
> > > do have a naming scheme based on version, with may date in the tag and
> > > some indication that it's not stable.
> >
> > I don't follow. I was proposing we continue with the existing scheme,
> > so the tag for today would be v2.4.
> >
> > All of our builds are tested to some extent, what I meant by "not
> > tested" was we would not have a freeze, release candidate, branching
> > or similar. It would be a commit that passed CI.
>
> And now I'm confused. :D  I thought the release schedule from the
> release working group was pushing to drive versioning from yocto
> versioning, versus our own separate versioning.

I had a read of the versioning committee's minutes, and didn't think
this would conflict with their work. This was more about something for
developer and low-level users to use in their day-to-day openbmcing.

Having a release process that says "OpenBMC Pluto is out! It has new
shiny" will be a great thing for the project and people making
products out of it. I think a tag in the git repo can exist in
parallel without taking value away from the broader release branding.

Please help me out if I've missed something here.