[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Advice on how best to handle non-backwards compatibility

On Fri, Jan 09, 2004 at 08:15:16AM +1000, Andrew Pollock wrote:
> 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.

Is the previous "master-filter" implementation no longer viable code?
Could you not grab it from an old version and ship it with the new

Steve Langasek
postmodern programmer

Attachment: pgpyd7DVSXN0z.pgp
Description: PGP signature

Reply to: