Eric suggested elsewhere using the git hash as build number, which could
work although might raise other issues.
Hash is not a bad idea, but it would have to be just a hash of public
method signatures.
An entire class Hash would cause a new implementation version at any
change in the body of the method, which would be counterproductive..
As I have already written, the easiest solution is to manually add the
implementation version to each ANB module and manually change them only
when changing the public method signatures.
This will ensure that a plugin will work over x versions of ANB..
Arsi
------------------------------------------------------------------------
*From:* Neil C Smith <[email protected]>
*Sent:* Friday, August 02, 2019 11:19PM
*To:* Dev <[email protected]>
*Subject:* Re: Aligning implementation and specification versions?
On Fri, 2 Aug 2019, 19:43 Tim Boudreau, <[email protected]> wrote:
We discussed this long ago, but if you want fewer friend dependencies, then
the solution is to get more of those through the API review process and
committed to as stable API. That's what it's for, and that's what actually
solves the problem.
It might solve that problem, it doesn't solve this problem! We're trying to
get to a situation where different builds of the same source get the same
implementation versions. It's something to consider in moving towards more
reproducible builds, and already caused an issue in this release cycle.
Eric suggested elsewhere using the git hash as build number, which could
work although might raise other issues. Hence wondering whether replacing
build number in implementation versions with the same text value as the
spec version might work instead. This wouldn't affect anything where the
implementation version is set in another way.
Best wishes,
Neil
