On Tuesday 05 April 2011 10:23:33 Matti Airas wrote:
> 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.

I agree, we just need to document it somehow, probably on our wiki.
 
> Cheers,
> 
> ma.
 

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside

Reply via email to