Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
REP 149: compatibility version #142
referenced this issue
Nov 10, 2017
Some feedback after reading the current draft:
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.
This is a long standing issue affecting all REPs. It would need to be fixed in the css and not in this PR: #127
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.
When the buildfarm is process package
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.
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:
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: