On 14.01.2021 16:43, Jacques Le Roux wrote:
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
Removing after a release branch is created is reasonable IMO (when
"release created").
--
Eugen Stan
+40720 898 747 / netdava.com
