[Cayenne-dev] Re: [jira] Created: (CAY-1310) Remove everything deprecated in 3.0

Then we need to un-deprecate them. I don't want us to be in a limbo
about deprecated API forever, and starting a new release branch is the
only chance to sort it out.

I will keep this particular method around until we have some
resolution. Also if you have other things in mind, please mention them
until I get rid of them.

Andrus

Well, I'm just looking at usual practice - e.g. Sun JDK still contains some
methods, deprecated ages ago. Also this allows user to update at once e.g,
from 2.0 to 3.1 without wondering, where the methods have gone.

2009/11/16 Andrus Adamchik <[email protected]>

I know. Sun is insane with their deprecation policies. The point of
deprecation is to give people a warning that something's going away
soon. Not to keep it forever.

Historically in Cayenne the deprecation timespan was between major
releases. I.e. the promise is that if something is "deprecated since
3.0", it won't be in 3.1. Anything more conservative than that would
just result in an unbelievable code mess.

In fact I am in favor of shorter major release cycles in large part
because we'll be able to evolve the framework faster (still giving
users a proper warning of course).

Andrus

It is logical to remove all old API when we *assume* that everyone who used
them has migrated. If 3.1 cycle will again be several years, then we should
remove everything :) If half a year or less - who knows. BTW I've seen users
asking about 1.2 version, which had last release years ago and I think it
was recommended to migrate to 2.0.
Anyways, feel free to remove that DataContext method as well.

2009/11/16 Andrus Adamchik <[email protected]>

I agree that we need to balance stability and the need to make
framework changes. I guess we can never achieve 100% pain free
migration experience for 100% of users, but we'll keep trying.

As an anecdotal evidence, a year ago I migrated a 1.1 (or was that
1.0?) Cayenne project to 3.0 for a customer. There were quite a few
removed methods. I don't have a very long memory, so I simply read
through all UPGRADE.txt files of intermediate releases, and quickly
found needed replacements, then applied them via find/replace. The
important part was that after this purely mechanical substitution the
old code just worked.

So actually having a red squiggle in Eclipse for a referenced removed
class or a method may actually be a good thing - it immediately points
a user to a problem (as long as there are docs that can help to solve
this problem).
Cool. I will proceed with this task then.

Andrus