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 <andru..bjectstyle.org>
>
>>
>> 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
This archive was generated by hypermail 2.0.0 : Mon Nov 16 2009 - 08:55:00 EST