Re: guava-libraries 18?
* Emmanuel Bourg:
> There is another point worth discussing I think. When we want to fork a
> package foo 1.0 because the version 2.0 is incompatible, do we:
>
> 1. duplicate the package foo as foo-1 and upgrade foo to the version 2.
> Every reverse dependency that doesn't work with the version has to be
> updated to use the new package foo-1.
>
> 2. fork and upgrade the package foo as foo-2. The package that need the
> new version depend on foo-2 and the other remain unchanged.
>
> While the solution 2 looks easier, it causes some embarrassing
> situations when foo-2 is upgraded. If the version 3 is compatible with
> the version 2 we end up with foo-2/3.0-1. We already have some
> packages in this case, like libasm4-java/5.0.3-1 and
> libplexus-utils2-java/3.0.15-1.
I favor the second option, simply because it forces less work on package
maintainers.
The source package name is largely irrelevant. The number that is part
of the binary package name only indicates that the package adheres to a
specific API/ABI compatibility level. One could theoretically pick any
arbitrary combination of letters and numbers instead, the only important
issue is that a binary package doesn't break API/ABI promises that have
been (implicitly) given by previous versions of the same binary package.
If there are concerns that users mistake the API/ABI compatibility level
for the major version of a library, it may be a good idea to put a
clarification such as "This package is compatible with versino x of the
FOO library." into the description of the libFOOx-java package.
I think that I am going to name the Guava package "libguava18-java"
(without the extra hyphen), for consistency reasons with the examples
you provided and because it looks less like a version number than in
"libguava-18-java".
I think that we are close to over-thinking it at this point. Most of our
users probably won't care at all about the naming issues.
> Regarding Guava 18, considering that only two packages failed to build
> with the new version, I'd prefer creating a guava-libraries-17 package
> and upgrading the main package to the version 18.
Again, this means extra work on other packages. (Two packages in this
concrete example may not seem much, but in the general case it may be
much more.) Additionally, not having to figure out right away what other
packages are affected by an API/ABI-breaking new version is a Good
Thing. After all, those reverse dependencies may be caught up in a
transition.
And for this concrete example: Breaking dependencies this close to the
freeze seems like a really bad idea to me.
Cheers,
-Hilko
Reply to: