Tom, On Wed, Apr 22, 2009 at 11:00:36AM -0500, Shawn Walker wrote: > Tom Mueller wrote: >> Shawn, >> >> Isn't the addition of the ProgressTracker methods that raise a >> NotImplementedError an incompatible change to the API? A program that >> extended ProgressTracker previously and worked without having an >> exception raised will now have an exception raised when these methods >> are called unless they do what you had to do in installupdate.py >> (implement empty methods). > > These are methods that subclasses need to implement, I'm not sure what > else I can do here. > > As far as I know, we've never made the decision how the progresstracker > class ties to the public client API and how the API might be rev'd. > > Also, as far as I know, the programs in the pkg(5) gate are the only > ones to implement progress trackers. As such, that particular aspect of > this change really isn't a concern for me.
I agree with Shawn on this one. The ProgressTracker is a separate interface from the versioned API that's exposed to client callers. Anyone who has extended a version of the ProgressTracker and left their code outside of the gate is essentially using a consolidation private interface. If you have a custom progress tracker that you'd like to avoid being broken by incompatible changes, I'd encourage you to integrate it into the pkg gate. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
