REP 149: compatibility version

[dirk-thomas]

The draft for REP 149 contains multiple different parts. In order to not mix the discussion on those topics in a single ticket this issue is meant to focus on discussing the introduced compatibility version represented by the compatibility attribute.

[NikolausDemmel]

Some feedback after reading the current draft:

1. Starting from the top, after reading Motivation and Rationale, it sounds like the idea of abi compatibility was planned, but abandonned due to lackign consensus. Maybe the "Rationale" section should mention, that instead of the abi_version, a "comaptibility" tag is introduced.
2. The section is center-aligned for some reason.
3. For the compatibility attribute, it is not clear how transitivity is handled. If I have successive releases, which are meant to be compatible, should I specify them each as compatible to its previous version, or to the oldest compatible version. I.e.:

<version compatible="1.2.0">1.3.0</version>
<version compatible="1.1.0">1.2.0</version>
<version>1.1.0</version>

vs

<version compatible="1.1.0">1.3.0</version>
<version compatible="1.1.0">1.2.0</version>
<version>1.1.0</version>

4. If the latter variant is used for my package foo, and some package bar depending foo is being released while foo is at version 1.2.0 and therefore it is built on the buildfarm against this version. Now if foo version 1.3.0 gets released, how does the buildfarm know that it is ok to not rebuild bar? It would need to potentially inspect all the versions of foo's package.xml. The same problem can arise in the other scheme.
5. Instead of dealing with transitivity, would it make sense to allow multiple compatible versions, maybe even version ranges?

[dirk-thomas]

1. Starting from the top, after reading Motivation and Rationale, it sounds like the idea of abi compatibility was planned, but abandonned due to lackign consensus. Maybe the "Rationale" section should mention, that instead of the abi_version, a "comaptibility" tag is introduced.

The semantic is pretty much exactly what was proposed and discussed before. The only real difference is the name of the attribute. So I wouldn't see how to describe this differently. Please suggest a specific rephrased text which makes it more clean.

2. The section is center-aligned for some reason.

This is a long standing issue affecting all REPs. It would need to be fixed in the css and not in this PR: #127

3. For the compatibility attribute, it is not clear how transitivity is handled. If I have successive releases, which are meant to be compatible, should I specify them each as compatible to its previous version, or to the oldest compatible version. I.e.:

<version compatible="1.2.0">1.3.0</version>
<version compatible="1.1.0">1.2.0</version>
<version>1.1.0</version>

vs

<version compatible="1.1.0">1.3.0</version>
<version compatible="1.1.0">1.2.0</version>
<version>1.1.0</version>

Any release has only one version tag. So it can declare up to which older version this version is compatible too. So if the different blocks are meant as successive releases both would be feasible. It basically depends if 1.3.0 is actually backward compatible to 1.1.0 or not (only 1.2.0) which of the two to pick.

4. If the latter variant is used for my package foo, and some package bar depending foo is being released while foo is at version 1.2.0 and therefore it is built on the buildfarm against this version. Now if foo version 1.3.0 gets released, how does the buildfarm know that it is ok to not rebuild bar? It would need to potentially inspect all the versions of foo's package.xml. The same problem can arise in the other scheme.

When the buildfarm is process package foo in version 1.3.0 it knows that it is compatible with 1.1.0. If the previous version of the package is in the apt repo that means that bar has been built in the past already. So there is no reason to rebuild bar. If the apt repo e.g. only contains version 1.0.0 of the package foo then the buildfarm also needs to trigger a rebuild of the downstream package bar .

5. Instead of dealing with transitivity, would it make sense to allow multiple compatible versions, maybe even version ranges?

I think I don't understand your question / case. I don't see how "transitivity" comes in year.

I also don't think that multiple versions should ever be defined as compatible. In a single distribution the version can also go up on each release (otherwise clients wouldn't even install the "newer" package if it has a lower version number than the one already installed on the system). So I don't see why there would ever be a need to declare compatibility with non-consecutive version ranges. Maybe you can clarify your question.

[NikolausDemmel]

Starting from the top, after reading Motivation and Rationale, it sounds like the idea of abi compatibility was planned, but abandonned due to lackign consensus. Maybe the "Rationale" section should mention, that instead of the abi_version, a "comaptibility" tag is introduced.

The semantic is pretty much exactly what was proposed and discussed before. The only real difference is the name of the attribute. So I wouldn't see how to describe this differently. Please suggest a specific rephrased text which makes it more clean.

Ah, I missread the reference to REP 127 as a reference to REP 149. Still, I think it could be clearer what is actually being proposed in this REP vs what happend in the the past with the following rewording:

• The early draft of REP 127 proposed an --> The early draft of REP 127 ("package.xml format 1") proposed an
• Since no consensus could be reached about specifying ABI compatibility --> Since at the time no consensus could be reached about specifying ABI compatibility
• It is also desired to be able to encourage more frequent releases if they don't require downstream packages to be rebuilt. --> add another sentence: This REP therefore introduces a "compatibility" attribute for the "version" tag.

Any release has only one version tag. So it can declare up to which older version this version is compatible too. So if the different blocks are meant as successive releases both would be feasible. It basically depends if 1.3.0 is actually backward compatible to 1.1.0 or not (only 1.2.0) which of the two to pick.

Ah, it wasn't clear to me that the compatibility means "compatible up to this version". Then it is clear that you have to always pick the oldest compatible version, and my point about transitivity is moot. Possible rephrasing:

Specifying the version the package is compatible with. --> Specifying the version up to which the package is compatible with, i.e. always pick the oldest compatible version.

[dirk-thomas]

with the following rewording ...
Possible rephrasing: ...

Thank you for the suggestions. I have applied them in 6e22080.

[NikolausDemmel]

Thanks!

[clalancette]

This is a long-dead discussion, and we merged in the related PR a long time ago. So closing this out.