[OE-core] Yocto Project 1.2 M4 schedule

[Koen Kooi]

Op 12 apr. 2012, om 11:02 heeft Richard Purdie het volgende geschreven:

> On Wed, 2012-04-11 at 01:51 +0100, Julian Pidancet wrote:
>> On 04/09/12 19:01, Liu, Song wrote:
>>> Hi all,
>>> 
>>> This is to restate and clarify the schedule for Yocto Project 1.2 M4 (milestone 4). If you are concerned or have patches you would like to merge, please see the following dates:
>>> 
>>> 1. RC3 official patch cut-off time: 12:00AM April 8th, 2012, PDT
>>> 2. RC3 build: April 11th, 2012, PDT
>>> 3. RC4 official patch cut-off time: 12:00AM April 15th, 2012, PDT
>>> 4. RC4 build: April 18th, 2012, PDT
>>> 5. YP 1.2 release: April 27th, 2012, PDT
>>> 
>>> You can also check out the schedule here: https://www.google.com/calendar/embed?height=600&wkst=1&bgcolor=%23FFFFFF&src=mg0m150m30gs891eqqhtfu5jgg%40group.calendar.google.com&color=%238C500B&src=sc7rov4ck552t2f0pav120t7r0%40group.calendar.google.com&color=%23528800&src=theyoctoproject%40gmail.com&color=%23182C57&ctz=America%2FLos_Angeles 
>>> 
>>> Please feel free to let me and Beth know if you have any concerns or questions.
>>> 
>>> Thanks!
>>> Song
>>> PM, Yocto Project
>> 
>> Hi,
>> 
>> I don't see any commits tagged for these milestones in
>> git.openembedded.org/openembedded-core at the moment. Will there be a
>> release tag or a release branch created on the git repository when YP
>> 1.2 comes out, to indicate people that there's a "stable" version of
>> oe-core they can use ?
> 
> 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.

regards,

Koen