Tagging master

Joel Stanley joel at jms.id.au
Thu Aug 23 00:12:26 AEST 2018


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.


More information about the openbmc mailing list