[Cubicweb] deprecation policy

Aurélien Campéas aurelien.campeas at logilab.fr
Tue Jul 24 17:55:42 CEST 2012


Le 24/07/2012 17:40, Sylvain Thénault a écrit :
> On 24 juillet 17:31, Aurélien Campéas wrote:
>> Dear list,
>>
>> I have seen the latest API change in 3.16: one adds a cw_set method
>> which unifies set_attributes and set_relations. Also the former
>> methods
>> get deprecated.
>>
>> In an ideal world, I'd:
>> * fix my cube's code to kill the deprecation warnings asap
>> * use a proper configuration management tool and be happy
>>
>> In my current world, I have
>>
>> * either to endure swaths of deprecation warnings (for such a
>>    basic&  widely used API) whenever I continue to develop with
>>    this version of cubicweb, because I do not want to immediately
>>    commit to it (esp. go in production with it),
>>
>> * or to adapt the code&  from this render my cube incompatible with
>>    former cubicweb versions
>>
>> These situations are problematic imo. Maybe I give too much
>> importance to these warnings. They tend to pollute quite a bit
>> the console however and the repetition of each warning gets
>> tiresome quickly.
>>
>> That happened also recently with e.g cw 3.15, where cubicweb.selectors
>> became cubicweb.predicates. Other than that there are some
>> important&  big changes in 3.15 but _this renaming alone_ created a
>> lot of visual noise.
>>
>> Maybe I'm just asking for an option to hide them ?
>> Or that we do not immediately deprecate old stuff ?
>> Or that we grow good enough configuration management tools ?
>
> My POV is that 3.16 introduce a method that allows to do the same thing
> as two previous methods (better btw :), and that I want to warn developpers
> using 3.16 that from this version they should use this method instead of the
> old one.
>
> The reason why deprecation warnings include the version number is that you
> have to be aware, when fixing a warning, that you break compatibility with
> earlier version. So IMO, yes, you're according too much importance to those
> warning: having warning for version earlier than the one you intend to
> support is fine.
>
> Now I aggree this sometimes clutters a bit the output and that a filtering
> tool to which we could tell "I don't care about cw warning for version>  3.15"
> would be nice.

Ok then, I'll dig http://docs.python.org/library/warnings.html then (as 
per Alexandre's suggestion).

>
> Regarding your third idea, I don't know what's a "good enough configuration
> management tool"
>

I'll talk about this later. Maybe a bit internally (@logilab) before on 
expanding on this list.

In short: I tried to use mercurial subrepos as a configuration 
management tool and it falls short.



More information about the Cubicweb mailing list