Re: gs-collections vs eclipse-collections

[Vincent Prat <vinceprat@free.fr>]

Hi Tony,

>> Should we package Eclipse Collections as a separate project (in which
>> case I will submit an ITP bug), or update and rename the existing package?
>> For your information, the package gs-collections has no reverse
>> dependency and has not been updated since September 2017.
> I see either choice as acceptable, but my suggestion is to update
> the existing package (and rename it only if you think it is necessary).
> It is the evolution of (and thus an update to) gs-collections.  This
> approach means you don't have to go through NEW, we don't have to
> introduce a new package to archive, and developers who know the software
> by gs-collections will still find it.  Even if there aren't r-deps in
> Debian, perhaps a downstream is using gs-collections and will benefit
> from the update without a rename.

What about developers who do not know the software and need Eclipse
Collections?
Do they have to guess that the Java package is provided by the Debian
package gs-collections?
Eclipse Collections is indeed the evolution of GS Collections, but the
latter still exists as such, even though only bug fixes are made.
By the way, the version present in Debian is out-of-date.

> If you decide to create a new source package for eclipse-collections,
> please also take the time to RM gs-collections.  We don't need to keep
> the old package around if we have a compatible replacement.  (I'm
> assuming that eclipse-collections is a drop-in replacement, or nearly so
> - maybe just a Java package name change?)

Yes, the Java package name is different. So, even if the API is
compatible, this would require downstream to change imports, classpaths,
etc.

In any case, since Emmanuel Bourg was the one who packaged
gs-collections in the first place, it would be nice to have his opinion
on the question.

Cheers,
Vincent