On Wed Sep 02 08:46, Michael Koch wrote: > IMO a possible solution would be to have two (or more) packages and let other > packages using jgrapht (Build-)Depend on the version they need. E.g. > libjgrapht-java > could always be the latest API and libjgrapht0.6-java is an older API which > some > apps can use. Only one of these packages may provide the jgrapht.jar link as > otherwise > we would need conflicts between the packages. When an app needs an older > version > of jgrapht it needs to explicitely reference the versioned jar (which would > not be a bad > idea anyhow as we otherwise force FTBFS on libjgrapht-java API updates).
This is better, but causes an FTBFS / broken package whenever a package was fine with any version but suddenly discovers that it's broken with the new one. I'd like to see a coherent policy across all of the Java libraries which allows more coordinated transitions, possibly aided by binnmus and library packages maintaining two versions in the archive for a while to ease the transitions. Discussion on the previous thread seems to have died out, but we should come up with a strategy before it becomes too late in this release cycle. Matt -- Matthew Johnson
signature.asc
Description: Digital signature
