[Openembedded-architecture] Notes from the OEDAM "Naming Table"

[Richard Purdie]

On Tue, 2016-09-27 at 12:53 -0700, akuster808 wrote:
> 
> On 09/27/2016 07:26 AM, Richard Purdie wrote:
> > 
> > On Mon, 2016-09-05 at 13:16 +0200, Martin Jansa wrote:
> > > 
> > > On Sat, Sep 03, 2016 at 12:04:26PM +0100, Richard Purdie wrote:
> > > > 
> > > > On Sat, 2016-09-03 at 12:14 +0200, Martin Jansa wrote:
> > > > > 
> > > > > My only 3 "naming" issues are:
> > > > > 1) The next release codename is decided only shortly before
> > > > > the
> > > > > actual release When I need to talk with management about
> > > > > plans
> > > > > for upgrading our builds to Yocto 2.2 release I'll probably
> > > > > reference it as "Yocto 2.2 (master)" while other releases are
> > > > > referenced as Yocto x.x (codename) - even worse when some
> > > > > internal things still have reference to "Yocto 1.7 (master)",
> > > > > because they were created before Dizzy was released
> > > > > and cannot be updated later.
> > > > > So in some parts it's easier to use numbers which should be
> > > > > known
> > > > > in advance (darn that mysterious 1.9 release which is still
> > > > > referenced internally and also on Yocto Project wiki pages).
> > > > > Knowing the codename of next release in advance (announced
> > > > > together with current release) would be very helpful for us.
> > > > This is good feedback. I'd not considered it in those terms and
> > > > there is no reason we can't announce the release names further
> > > > in
> > > > advance. I will admit I haven't actually decided on what 2.2
> > > > will
> > > > be called but that doesn't mean I can't get a move on with
> > > > these!
> > > > :)
> > Sorry, I'd forgotten to get back to this. 2.2 will be known as
> > "morty".
> > 2.3 will be known as "pyro".
> Does have the same "code names" in Yocto and OE add to the naming
> confusion?

If some repos use one release name and others use a different branch
name, I really can't see that helping things? 

The whole idea of this name is to give some way of knowing what should
work with what. I thought I'd written about and explained the reason
for that fairly recently on this list?

Cheers,

Richard