On 04.04.2011 13:03, ext anatoly techtonik wrote:
On Mon, Apr 4, 2011 at 12:46 PM, Matti Airas<[email protected]> wrote:
I like both the one-argument version and the mapping interface ideas. The
API should've been like the one-argument version from the beginning, but now
that the C++ style version is out there, I guess both styles need to be
supported...
Time to think about deprecation policy and markers?
Yes, absolutely!
In principle, backwards-incompatible API changes were supposed to happen
only in the major (X.0.0) releases, while the minor releases (0.Y.0)
were reserved for C++ ABI breakage and patch releases (0.0.Z) for
bugfixes and minor feature additions. According to this scheme, API
deprecation would only happen with the major releases, but I don't think
this would be practical, because the major releases will most likely be
very infrequent.
How about allowing deprecation of simple API features (basically,
changes in specific function signatures etc) in the minor releases?
Then, when a feature is marked deprecated the deprecated feature could
be removed in the next minor release after a suitable cool-down period.
I'd propose a cool-down period of a minimum of one year between the
deprecation and the feature removal to give application developers ample
time to update the APIs in their applications.
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside
