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. 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. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544faa82.5090...@apache.org
