[Catalog-sig] disallowing the removal of packages?

[Martijn Faassen]

Hi there,

On Tue, Jul 5, 2011 at 9:51 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> I *personally* think you are exaggerating your case. If you are using
> a package, avoid sticking to a specific version of the software, and
> instead write the package in a way that will work with many versions
> of the library. If the library is too unstable, don't use it at all.
> If the library has an incompatible change, report it as a bug; if
> the author can bring convincing arguments why there must be that
> change, cope with it.

I have about 5 years experience doing this. We started out doing it
the way you suggested it in 2007. It didn't work. We got constant
breakage. Users of your collection of packages would have to be lucky
to download them on a day when it was all working perfectly. Everybody
developing these packages were intelligent people working in good
faith trying to preserve backwards compatibility, but things broke
anyway.

If you maintain the collection of packages you are willing to try
upgrades to new versions of libraries and run the test suits to see
whether it works, but if you then hand this collection of packages to
other people that might start use it at unpredictable times, you want
to hand them something that is guaranteed as much as possible to work.
This applies to development teams when you just want to start working
instead of having to deal with "oh this upgrade broke my build" all
the time, and it also applies to open source projects which hand out a
large collection of packages to users.

[repeated]
> I *personally* think you are exaggerating your case.
...
> IOW, just don't use old versions when newer versions are available
> and maintained.

This leads me to conclude that I personally think you have not the
same kind of experience with this issue as I do... I think you haven't
been using packages on a scale I have been doing for years now.

>> It can't be that it's considered good practice to change the contents
>> of an older release, or to remove one, right?
>
> Right. And it can't be considered good practice to rely on software
> that follows bad practice, right?

I can't predict this in advance. I have been using this software for
years, and suddenly it was removed. It's also rather facile of you to
say that I can easily switch to something else when this happens -
sometimes it's the only game in town.

> Don't use software that deletes old releases while making unjustified
> incompatible changes in new releases, or otherwise doesn't provide
> clear backwards compatibility statements and migration strategies.

Sorry, I can't see the future like you do. I also use packages that
have imperfect maintainers that sometimes make incompatible releases
by mistake; compatibility issues can be very subtle.

Anyway, you're just telling me very loudly I don't have a problem,
right? You're convinced I am doing it the wrong way. So should I just
go away?

Regards,

Martijn