Hi
> Am 08.12.2015 um 09:49 schrieb Thomas Mueller <[email protected]>:
>
> 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.
Just to be clear, this is not about Sling vs. Oak.
This is whether Oak can support semantic versioning of its exported API. If you
find, that Oak cannot do it. Fine, then don’t do it.
As a consumer I will have to live with uncertainties. But that is still better
than being misleaded.
>
> 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 ?
to get C you also need A and B and hence would be at 2.1
* you cannot do 1.1 because this means feature A but neither B nor C
* you cannot just do 2.1 (or even 2.2) because you are omitting both
A and B and thus consumers of 2.1 (or 2.2) expecting A or B besides
C would break
* you cannot do 3.x because this would later break migration to
trunk which is 2.1
> ... later on ...
> backport feature A => bump export version to ?
Since you already have C you already have A (and B) and hence are at 2.1
already.
Please note, though: This is *not* about an implementation detail. This is
about something visible like a new public (or protected) method or a
class/interface.
Semantic versioning is about resonating about something and agreeing on what
level of compatibility I as a consumer can expect from the provider/producer -
consider it being the part of an API contract dealing with evolution. It comes
with a price for the provider/producer. If the provider is not able to abide by
this contract, I suggest not to enter it.
Regards
Felix
>
>
> 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
>>
>>
>>
>
