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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core