> Hi Daniel,
>
> Quite a good question, we had similar discussions before.
>
> An old one is
https://markmail.org/message/rlksriqjznsndq2g>
> The end of last one is
https://markmail.org/message/4aia3v5ugjjajmhf>
> It's documented for services at
https://s.apache.org/6ophi>
> We currently have 201 @Deprecated occurrences in Java classes (121 in
> 2008).
> Apart by looking for revision information, in Java code we miss the date
> when the deprecation took place.
>
> I answered to David's proposition in the 1st thread above
>
> <<I will vote for "just after the release is created".>>
>
> If we agree that "release created" means creation of a new release
> branch (and not releasing a package which would be confusing for
> packages inside a release branch), we could, as suggested recently,
>
> 1. create a R21 branch
> 2. Remove all the currently deprecated methods in the trunk (and not yet
> in R21?)
> 3. Document this process in in the same place than above in the wiki
> 4. Use this process for each new release branch created
>
> What do you people think?
>
> What about not removing in trunk before creating R21 as I believe most
> deprecations are old if not very old ones?
>
> Jacques
>