[OE-core] Branched for release

[Khem Raj]

> On Oct 1, 2015, at 8:37 AM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
> On Thu, 2015-10-01 at 07:28 -0700, Khem Raj wrote:
>> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>>> Just a heads up for people that we've branched for release and that
>>> jethro branches are now available. Bitbake branched as 1.28, I decided
>>> to save bitbake 2.0 for another occasion.
>> 
>> what would be the occasion ?
> 
> Memory resident Bitbake? Toaster developments? Logging improvements? New
> shell commands?
> 

bitbake is tied ot OE metadata, even though its a separate repository, it can be viewed
as any other metadata layer.Moreover I don’t know if there are any other projects besides OE using
it. All above look good features but not clear whats there relation to bumping major release
number. Do they make 1.9 incompatible in some different ways than that we don’t do between 1.x releases ?

>> this time lets branch consistently. Across different repositories
>> please.
> 
> Bitbake is the only repo which doesn't use the branch codename. I did
> write at length about how version numbers as branches would actually
> cause much more pain than any problem they solve, bitbake is one of the
> few exceptions to that given its a tool, not metadata and has a more
> consistent history where the version number means something specific and
> is actively used.
> 
>>  I would also suggest to not use codenames in branches
>> but rather the numbered release. If we want to use codenames for
>> branches then lets drop the numbered release names.
> 
> The number does have some uses, its really not that simple.
> 

They do tell me the chronology of releases I get that but then I don’t understand
why can’t be use it in name for branching then, why does it have to be no relation
between branch and release names ?

I am not sure if you are aware enough of the confusion it causes to new users, not all distros
use combo layer like tools to fudge the layer identities and create a new repositories where this can be less
of the problem since the new repository could have its own versioning scheme.


> If we want to discuss this all again, so be it, but on the eve of
> release really isn't the time to start it all again.

so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?

> 
> Cheers,
> 
> Richard
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151001/8945236a/attachment-0002.sig>