cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] Created: (CAY-1310) Remove everything deprecated in 3.0
Date Mon, 16 Nov 2009 13:54:27 GMT
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 <andrus@objectstyle.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


Mime
View raw message