db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: auto-XXX setting (PART II)
Date Tue, 23 Mar 2004 01:45:28 GMT
Brian McCallister wrote:

> 1.0.1 doesn't need to be solely bug fix -- but it should avoid major new 
> functionality.
>
> Adding this, if it doesn't break any regression tests, should be fine in 
> 1.0.X imho.
>

Each 1.0.x version should be more stable than the prior one. That's why 
I think rc6 will be ok for check in, because then have one week (till 
final 1.0) to find any side-effect (I don't expect side-effects, but 
maybe...)

Another reason is that I don't want to do parallel development (1.0 
branch and CVS trunk). After the final 1.0 I want concentrate work on 
1.1 and only do major bug fixing for 1.0.x.

> In fact deprecating in 1.0.1 and removing the old way in 1.1 is fine in 
> my mind -- as 1.1 is a long ways off yet.
> 

Is the finish line 1th June for 1.1rc1 a long way off? ;-)

regards,
Armin

> -Brian
> 
> On Mar 22, 2004, at 8:08 PM, Armin Waibel wrote:
> 
>> Antonio Gallardo wrote:
>>
>>> Brian McCallister dijo:
>>>
>>>> On Mar 22, 2004, at 4:26 PM, Armin Waibel wrote:
>>>>
>>>>
>>>>> Now the question is should we check in the new full backward
>>>>> compatible auto-xxx stuff before 1.0 (with updated documentation) or
>>>>> wait until 1.1?
>>>>
>>>>
>>>> 1.0.1 or 1.1 at the earliest, I would think. I would like to keep API &
>>>> Configuration frozen until 1.0.
>>>
>>> +1
>>> The old way must work as today.
>>>
>>
>> That will be no problem the old way will work as today, because I'm 
>> from Old Europe ;-)
>> For auto-update and auto-delete we introduce new types NONE, LINK, 
>> OBJECT and the old FALSE,TRUE will also work like before. For 
>> auto-update LINK <=> FALSE, auto-delete NONE <=> FASLE
>> and TRUE is always the same as OBJECT.
>>
>>> You can deprecate it in 1.0 and delete it in 2 or 3 future releases.
>>
>>
>> I can only deprecate it in 1.0 if I check in the new stuff, because 
>> deprecate it without allow the user to use the new handling doesn't 
>> make sense in my opinion or I'm wrong and it's a matter of common 
>> knowledge to do that?
>>
>> regards,
>> Armin
>>
>>> This
>>> is the way to avoid problems for users that already using this stuff. 
>>> You
>>> need to give then the alarm and time to change to the new stuff.
>>> Best Regards,
>>> Antonio Gallardo
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message