I think having an official deprecation policy like Guava's is a good idea, and I'd support going with Guava's to start with.
There is the issue though that Guava is purely a Java library (?) so it can uniformly deprecate things via the @Deprecated annotation, whereas GWT has many non-Java things we might want to deprecate (command-line flags and browser support come to mind) so we need an official way to deprecate those features/functions too. I think just mentioning them in the release notes is a good way to mark them officially deprecated (but we should also try to warn users more directly when possible). Lastly, we should decide if we want to grandfather in some existing things as deprecated, or whether they should all go through the same deprecation process. E.g., I think Visibility.LegacyPublic is reasonably considered deprecated since its Javadoc discourages use, but it's not actually marked @Deprecated. And I use this just as an example; I think it's safe to kill now, but if there's any concerns about setting a bad precedent for other removals, then I'd support just marking it @Deprecated for now instead and waiting a few releases before removing it. On Sat, Aug 31, 2013 at 4:35 PM, Thomas Broyer <[email protected]> wrote: > Hi all, > > We don't have a deprecation policy. I've heard a while ago that things > were supposed to be removed 2 releases after they've been deprecated; in > practice, things had been left deprecated for a while (we still have event > listeners and DeRPC; there are a few users inside Google which hold their > removal, but we should have got rid of them by GWT 3.0). > > Since the Steering Committee was created, I think I brought this issue at > least twice, and I don't think anybody commented on it. > > In light of https://gwt-review.googlesource.com/4321 and > https://gwt-review.googlesource.com/4324, I'd like to spawn the > discussion again; this time on gwt-contrib rather than limited to the SC. > > I like Guava's deprecation > policy<https://code.google.com/p/guava-libraries/wiki/PhilosophyExplained#Iteration> > (copied > here for reference): > > Deprecated non-beta APIs will be removed eighteen months after the release >> in which they are first deprecated. You must fix your references before >> this time. If you don't, any manner of breakage could result (you are not >> guaranteed a compilation error). >> > […] > >> If we decide to delete a @Beta feature, we will typically deprecate it >> for one release before deleting it. > > > I think we should just use the same; particularly now that we chose to > (try to) release twice a year (18 months would mean an API would be > deprecated for roughly 3 releases before being removed; I'd actually prefer > a 12-month == 2 releases deprecation notice). > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
