Tagging master

[William Kennington]

We could do point releases on the major topic like 2.4.x for all tags
before 2.5 but after 2.4. It wouldn't really follow semantic versioning
since it doesnt only contain bugfixes. But if we cared about that we could
just do 2.4.0.y for bugfixes on a 2.4.0 branch.

On Wed, Aug 22, 2018, 07:08 Patrick Venture <venture at google.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180822/f9c607c7/attachment.html>