Review by @SethTisue .

Hi Jorge. Couple of suggestions,

• Add a deprecated annotation to the class as well
• Use 2.11.8 (the version the deprecation will become effective) for the since val

scala.Responder is a good example to follow. In fact the deprecation messages from Responder could be used as-is,

This class will be removed
This object will be removed

The reasons for deprecating can be included in the commit body instead.

Make these changes, amend the commit and force push your branch.

Sorry about that. I did not remove deprecatedInheritance. Shall I?

yeah, if it's @deprecated, then everything about it is deprecated, so there's no more need for an annotation that only deprecates a single aspect of it

The next step is to update test to expect the deprecation messages,

From https://scala-ci.typesafe.com/job/scala-2.11.x-validate-test/1481/console

fail - run/t3647.scala  [output differs]% scalac t3647.scala

@jvican - Because PagedSeq is now deprecated the compiler is emitting warnings which the test needs to accomodate.

This entry from the end of the build log is the starting point,

% diff /home/jenkins/workspace/scala-2.11.x-validate-test/test/files/run/t3647-run.log
/home/jenkins/workspace/scala-2.11.x-validate-test/test/files/run/t3647.check--- empty

t3647.check does not exist because prior to this commit PagedSeq did not generate warnings. Now the diff is non-empty,

+++ t3647-run.log
@@ -1,0 +1,1 @@
+warning: there were three deprecation warnings; re-run with -deprecation for details

Fix this by adding t3647.check with this content,

warning: there were three deprecation warnings; re-run with -deprecation for details

t6292.scala & t6292.check make a good example of how to educate the tests on the new deprecated status.

/rebuild

for the deprecation message, perhaps "This class will be moved to the scala-parser-combinators module"?

LGTM

LGTM

Note that we usually try to avoid deprecating in a minor release, since this can break people's builds when they run under -Xfatal-warnings.