Menu
▾
▴
Re: [Gimp-print-devel] 5.2?
|
From: Michael R S. <ms...@ap...> - 2008-03-29 16:23:22
|
Robert Krawitz wrote:
> Date: Fri, 28 Mar 2008 10:42:23 -0700
> From: Michael R Sweet <ms...@ap...>
>
> Robert Krawitz wrote:
> > ...
> > I think it would be really, really (really! :) useful to keep the
> > PPD files compatible in micro/patch releases, such that a vendor
> > could ship 5.2.x and provide updates without worrying about the PPD
> > files changing within that minor release series. Obviously new
> > drivers will need new PPDs, but existing drivers shouldn't need
> > updated PPDs when you don't add a feature.
> >
> > Well, we already provide a PPD file generator ("driver") and a script
> > to update PPD files. So a distributor who wants to ship an update
> > just has to have the postinstall script run cups-genppdupdate.5.2 to
> > update the PPD files.
>
> Yes, that's exactly what I'd like to avoid in the general case.
> 99.9% of all updates do not change the PPDs for existing drivers, so
> why should we churn every Gutenprint queue for a simple bug fix?
>
> What's the problem with doing this? The postinstall script can do it
> on the fly. It doesn't require rebuilding the queue. In any event,
> every upgrade that could possibly be from an earlier minor version
> would have to be prepared to do the update anyway.
Most of the time it is extra unnecessary processing...
> ...
> Well, actually most releases have at least some changes that affect
> at least some PPD files (and I'm not including explicit PPD file bug
> fixes). We support so many printers (over 800, with something over
> 150 distinct printer models at last count) that it's very easy for
> *something* to have to change. Even adding a new paper type, for
> example, causes a PPD file to change.
Yes, but adding a paper type shouldn't render existing PPDs
incompatible, and in that case we'd only want to update the PPDs for
that particular driver.
Most of the changes below shouldn't make existing PPDs stop working,
and only affect one class of drivers. It makes more sense to allow
PPDs with the same minor version to continue working, and add a
per-driver version number such that the PPD files would contain:
*FileVersion: "major.minor.driver"
This would allow the PPD upgrade logic to only update those queues
that need it, and we could keep compatibility between minor releases
*without* forced updates.
> Looking at the 5.1 release sequence:
>
> In 5.1.7, the following changes needed PPD changes:
>
> * Some of the PictureMates were incorrect (some of them are 4-color
> printers, not 6-color).
How did this need a PPD change?
> * Add 2880x2880 and 5760x2880 on C120
>
> * Fix envelope printing on a lot of printers
>
> * Fix paper positioning on many laser printers (needed new input
> slots for adjustable guides)
>
> * Add settings for some new RIP parameters
???
> 5.1.5:
>
> * Add Ordered New
>
> 5.1.4:
>
> * Change paper size for CD - Custom
>
> * Don't use 5760x2880 for automatic quality settings
Isn't that decision done in the driver?
> 5.1.3:
>
> * Fix margins for Canon printers
rastertogutenprint already handles margins separately from the PPD
file...
> 5.1.2:
>
> * Retune Claria-based printers (added some resolutions)
>
> * Extend range of sizes for custom CD printing
>
> 5.1.1:
>
> * Rename some Canon printers
This would mean a minor release change with my proposal...
> * Enable print to CD's for some Canon printers
>
> * Fix resolutions for S300
>
> 5.1.0:
>
> * Fix borderless printing (add shrink/crop/expand option)
>
> * Change resolutions on some Canon printers
>
> * Fix roll printing on R800 (maybe)
>
> In the same time, you've added support for a lot of new printers,
> and *those* changes did not require new PPDs for things to work.
>
> My point is this - in the general case there will be *less* churn,
> and when new features are added there will be the same amount of
> churn as we have now.
>
> Well, most of the 5.1 releases (87% -- everything but 5.1.6) have
> required at least some PPD files to change for added, changed, or new
> features -- not new printers.
Right, but few of the changes required a new PPD and most of them
were localized to specific drivers. Also, the focus on 5.1.x has not
been on stability, so a better comparison would be to look at the
changes in 5.0.x.
Anyways, my desire is to see a more frequent stable release cycle for
Gutenprint, which means minimizing the changes that are forced on
users (i.e. unnecessary PPD upgrades) and more structured/incremental
improvements to the core. 5.1.x has been a long-running developer
release that could easily have been 2 "stable" minor releases - 5.1.x
with the new color/driver arch changes and 5.2.x with the new dither
algorithm.
Assuming that we can make every (non-beta) release a stable one, the
PPD versioning and unnecessary updating of PPDs isn't a show-stopper
for me. But I sure would like to minimize "PPD churn" if we can.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|