Tagging master

[Patrick Venture]

On Wed, Aug 22, 2018 at 7:04 AM Joel Stanley <joel at jms.id.au> wrote:
>
> On Wed, 22 Aug 2018 at 23:30, Patrick Venture <venture at google.com> wrote:
> >
> > On Tue, Aug 21, 2018 at 6:09 PM Joel Stanley <joel at jms.id.au> wrote:
> > >
> > > Hello,
> > >
> > > I would like to propose we create a tag of master.
> > >
> > > The tags are useful for those who are working on openbmc, but also
> > > supporting fellow developers and testers who may be working on the
> > > host firmware, operating system or other tools like openstack. When
> > > they have issues, a glance at the tag give us a rough idea of how old
> > > their firmware is. As a developer, this gives me a rough idea of what
> > > kind of issues to expect, but also how far I should dig before
> > > suggesting "you need an update".
> > >
> > > I suggest we use tags as a lightweight epoch in our commit history.
> > > They don't need to carry any additional meaning beyond being easier to
> > > pronounce than 006d86903586b1dde915f5b0d90a68fd31935095. This means
> > > there's no garuntee that a tag contains new features, or has had any
> > > more testing than any other commit.
> >
> > 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.