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).

Anyways, feel free to remove that DataContext method as well.

Cool. I will proceed with this task then.

Andrus

On Nov 16, 2009, at 3:30 PM, Andrey Razumovsky wrote:

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]>


On Nov 16, 2009, at 3:14 PM, Andrey Razumovsky wrote:

Sun JDK still contains some
methods, deprecated ages ago.


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




--
Andrey

Reply via email to