[OE-core] Yocto Project Branch/Release Naming

[Richard Purdie]

On Wed, 2012-04-18 at 11:28 +0200, Koen Kooi wrote:
> Op 12 apr. 2012, om 11:02 heeft Richard Purdie het volgende geschreven:
> > Yes, there will be a branch created on OE-Core. 
> > 
> > At this point the actual branch naming/tagging is a little in flux.
> > There was some discussion about this at collaboration summit and the BSP
> > summit but there was no conclusion.
> > 
> > I've tried to write an email on the subject and it basically goes around
> > in circles. Ideally we need a scheme which can be used in all the layers
> > which doesn't contain numbers as these may conflict with various layer
> > schemes. The poky release names at least do that. Ideally people also
> > want something sortable with more context such as the year. Doing this
> > without numbers is harder.
> > 
> > I'm reluctant to change the numbering/branch scheme at this point in a
> > release as its unfair to release engineering and the documentation
> > maintainers.
> 
> Any update on this? I'd like to have the angstrom scripts and
> repositories ready before the end of the week and having some form of
> agreement on branch/tag naming would be awesome.

I've been giving this a lot of thought. Whilst I didn't say much in this
thread, I did read it and am considering everything that was said.

The most logical initial choice would be "yocto-project-1.2". I think
that real world use of it would cause several problems though. The
number in the name creates conflict for a start. If you want to release
version X of a BSP/Angstrom/OE-Core/Poky or even bitbake, figuring out
the relationship between 1.2 and the local release numbering is hard and
confusing. I don't really want to impose a unified numbering system with
the Yocto Project, particularly as many components have numbering
systems already.

I'm already conscious of the "When will there be a Yocto Project 2.0"
and I think these numbering schemes are artificial for that reason.
Also, Yocto Project is a trademark and I know there are discussions
going on at the moment about how/when it should be used and so on. I
can't imagine there being a problem in this area but we should really
let those discussions conclude which they have not as yet.

Finally, I think its unfair to pull the rug out from under release
engineering by changing things at this stage of a release.

So, I therefore want to continue to use codenames for the release
branches and this release will be "denzil".

The main downside to these codenames is the lack of sorting which I'm
going to categorize as unfortunate.

It therefore follows based off my comment above that tags will continue
to use the version scheme used by the specific projects. 

I am going to encourage "denzil" branches in repositories to show
compatibility and strongly recommend to the OE TSC that we have a denzil
branch in the OE-Core repository instead of 2012-1. Bitbake is the one
exception I'd make to the denzil branch naming scheme, not least as its
supposed to be backwards compatible and work anywhere so the branch
naming applies to metadata and not bitbake.

We can tag OE-Core as 2012-1 if so desired although I am starting to
dislike that version scheme for its bad handling of point releases (it
looks like a date). I guess that is a discussion for the next TSC
meeting.

So we have a decision, I'm not sure everyone will love this but such is
life.

Cheers,

Richard