Tagging master

Joel Stanley joel at jms.id.au
Thu Aug 23 00:04:07 AEST 2018


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.


More information about the openbmc mailing list