Phillip J. Eby wrote: > Removing <namespace> is of course the potentially controversial bit, soif you know of any reasons why it should remain, or have any input as to what the deprecation period before its removal should be, please respond. Thanks!
If I remember correctly, this was added for the convenience of xslt processing. We were doing this to generate docs a while back, but we haven't been doing that for some time. (Morgen uses the repository directly instead). I'm in favor of removing it. +1
FYI, only two Chandler parcels besides Zaobao use it: 'core' and 'osaf'. (And I removed the usage from Zaobao because it was no longer needed.)
The only reason that core and osaf need it, is because the parcel manager doesn't provide a default namespace for top-level parcels. But this is a one-line fix that I expect to make today, following which the two remaining <namespace> uses can be removed.
As for the deprecation period -- the only factor I can see here is that it would be nice if the sprint parcels worked with the trunk through the end of May, so that we still have the option of using the trunk for demos of these parcels in May.
So, should we have introduce a deprecation warning during that period (i.e., the parcel works but a warning appears on stderr), or should we use PendingDeprecationWarning instead and wait until the next milestone to introduce the DeprecationWarning?
(I'm making the projection/assumption here that we're following the Python language's conventions for informing developers that they're using deprecated features. This may be overkill or underkill in Chandler's case, but it seems like a reasonable approach by default.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
