Re: Advice on how best to handle non-backwards compatibility
On Thu, Jan 08, 2004 at 10:01:43AM +0000, Andrew Suffield wrote:
>
> Ah. Yes. That's not quite what I was expecting - it's not lprngtool
> that breaks when you upgrade, it's the printcaps that the old version
> generated.
>
> There's basically only one solution here - *don't* upgrade, at least
> not automatically. That means you change the package name, so people
> who were using the old version will continue using the old version.
Hmmm. Okay, so lets say I ask the RM to yoink the lprngtool from testing and
ftpmaster to yoink it from unstable and I upload the new one as
lprngtool-1.3 or something...
This leaves things such that the lprngtool version in stable no longer
exists (unless I grab it from snapshot.d.n or something and reupload it) and
when sarge is released, there'd be lprngtool and lprngtool-1.3. I guess I
could make mention of lprngtool-1.3 in the lprngtool package for those that
wanted to upgrade... Would that warrant a mention in a Debconf note?
Or do we leave lprngtool (the original) out of the archive, and just provide
lprngtool-1.3 and hope that people do an apt-cache search to find it's
there?
> I'm not sure whether the old version should continue to provide the
> configuration interface (I'd guess that it should, but maybe you can
> do something that works better), but you definitely don't want to let
> it upgrade to a version that doesn't provide the filters - there's a
> big difference between breaking a configuration tool, and breaking
> printing entirely.
Amen. I'm not sure how much wholesale change I want to make to the 1.1.1
package's innards though. At this stage, I'm interested in packaging
software for Debian, not taking over the software altogether...
> It's not perfect, but it's the best we can do when upstreams don't
> provide an upgrade path (and it happens too damn often).
Mutter mutter.
Andrew
Reply to: