Hi,
I think the main difference between Oak and Sling is, AFAIK, that Sling is
"forward only", and does not maintain branches, and does not backport
things.
In Oak, we add new features in trunk (changing the API), and backport some
of those features, and not necessarily all of them, and not necessarily in
the same order as they were implemented:
== Trunk ==
add feature A => bump export version to 1.1
... later on ...
add feature B => bump export version to 2.0
... later on ...
add feature C => bump export version to 2.1
== Branch ==
backport feature C => bump export version to ?
... later on ...
backport feature A => bump export version to ?
Regards,
Thomas
On 08/12/15 09:41, "Michael Dürig" <[email protected]> wrote:
>
>>> Packages evolve independently, but they do in potentially
>>> divergent branches. This is the kind of timeline that we usually
>>> face:
>>>
>>> - Oak 1.4 has a package org.foo.bar 1.0 - Some changes happen on
>>> the development branch 1.5 - Oak 1.5 now has a package org.foo.bar
>>> 1.1 - A change X happen in the development branch 1.5 - Oak 1.5 now
>>> has a package org.foo.bar 1.2 - The change X has to be backported
>>> to the maintenance branch 1.4 - Oak 1.4 now should have a package
>>> org.foo.bar 1.1
>>>
>>> Assuming that the versions were incremented following the semantic
>>> versioning rules, we now have two packages - both called
>>> org.foo.bar and both having version 1.1 - that live on two
>>> different branches and contain different code.
>>>
>>> The only obvious solution that comes to my mind is to bump the
>>> major version of every package right after the development branch
>>> 1.5 is started, but I don't like this approach very much because it
>>> would break compatibility with existing clients for no obvious
>>> reason.
>>
>> This scenario is the exact problem you are facing while branching and
>> evolving the branches in parallel to trunk.
>>
>> The only end-developer friendly solution is to byte the bullet and do
>> it really properly and make sure you evolve exported packages (being
>> your API) in a truly diligent matter: Consider a package name and its
>> export version as the package¹s identity and always make sure this
>> identity (label) refers to the identical exported API.
>>
>
>I fail to see how this would work with branches. For Francesco's example
>this would mean that we'd need to backport everything into the branch
>effectively aligning it with trunk and thus obviating its purpose.
>
>Michael
>
>
>
