2011/4/13 Branko Čibej <brane_at_e-reka.si>:
> On 13.04.2011 14:04, C. Michael Pilato wrote:
>> On 04/13/2011 06:17 AM, Julian Foad wrote:
>>> Are you saying we *do* support running a mixed set of Subversion
>>> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
>>> under the impression we had a policy of "you must upgrade (or downgrade)
>>> the libraries as a complete set, not individually".
>> As was I. [Insert disclaimers similar to Julian's here.]
>
> I agree such a policy would be useful. But I can't find it in the
> version compatibility guide. That said, I'd support adding such wording,
> and relaxing the compat guidelines in general. They're useful, but have
> turned out to be somewhat too restrictive in practice.
When I wrote the versioning guidelines (a decade ago!), it was only
concerned with a *single* library's compatibility. I never considered
"Best Principles" for a coordinated release of a group of libraries.
I think it would be fair to amend the versioning guidelines to specify
requirements of library groups.
Same-version makes the private intra-library calls much simpler to
maintain. Allowing different patch levels places more restrictions on
us, as developers, to be wary of changes to our private APIs.
But... I'm not sure whether we truly want to state "each library in a
group must be at the same version". Consider a project that wants to
release a security fix for ONE library, and explicitly NOT touch or
release the other libraries. You now have (say) 7 libraries at 1.4.3,
and one at 1.4.4. That seems a perfectly acceptable approach, and
sysadmins might even prefer to avoid bumping libraries that have no
semantic changes.
The guidelines were targeted towards sysadmins with the idea, "you are
always safe to upgrade in order to fix a bug. no other software on
your box will break if you blindly apply updates." Without that
guarantee, updating a release becomes a massive staging process to
find third-party code that now breaks. (ref: Python version upgrades)
So... I see both sides here, but am not sure of the best path forward.
Cheers,
-g
Received on 2011-04-13 20:28:42 CEST