You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/02/15 17:43:44 UTC
[OT] RC duration; was Re: API changes in Criteria before Release 1.0
Have we really been in RC for almost a full year?! That isn't good.
-Brian
On Feb 15, 2004, at 11:31 AM, Jakob Braeuchi wrote:
> hi larry,
>
> those methods are deprecated since 11 months between RC1 and RC2.
> this means we'll have to live with them until 1.1.
>
> jakob
>
> Larry Streepy wrote:
>
>> To me, the question boils down to when the methods were deprecated.
>> If
>> there was a real release in which the methods were deprecated, then
>> in a
>> subsequent release they can be removed. Now, exactly how many
>> releases you
>> wait is a matter of policy and the level of change you expect your
>> consumers
>> to deal with.
>> I don't know when these methods were deprecated. If it was part of
>> the
>> string of RC's, then they should not come out in the final 1.0. I
>> don't
>> know the history of OJB, so I don't know if there was an "official"
>> 0.9 or
>> something that everyone considered a true release of the product. If
>> there
>> was such a beast, and the methods were deprecated in that release,
>> then it
>> would be reasonable to remove them in the 1.0 final release.
>> This may be open source, but people depend on these API's to
>> implement real
>> products. Thus, you need to treat OJB with the same level of care and
>> provide a reasonable level of stability in the API. It's just good
>> product
>> management.
>> Thanks.
>> Larry.
>>> -----Original Message-----
>>> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
>>> Sent: Sunday, February 15, 2004 6:16 AM
>>> To: OJB Developers List
>>> Subject: Re: API changes in Criteria before Release 1.0
>>>
>>> hi brian, erik,
>>>
>>>
>>> Brian McCallister wrote:
>>>
>>>
>>>> Anything marked as deprecated in 1.0 should have an expectation of
>>>> removal in 1.1
>>>>
>>>> I agree that 1.01 should not have client API changes.
>>>>
>>>
>>> that's exactly why i wanted to remove it _before_ 1.0.
>>>
>>> jakob
>>>
>>>
>>>> -Brian
>>>>
>>>>
>>>> On Feb 13, 2004, at 7:39 PM, Erik Forkalsrud wrote:
>>>>
>>>>
>>>>> I don't consider myself an OJB developer, so feel free to ignore
>>>>> this, but I must say that I disagree with the reasoning here.
>>>>>
>>>>> If the 1.0 release is going to mean anything at all, I would expect
>>>>> it to mean API stability, so all API changes like this should go
>>>>> in
>>>>> before 1.0 final, or wait until 2.0. If I build an application
>>>>> that
>>>>> uses OJB 1.0, any user of that application shouldn't need to worry
>>>>> about upgrading to OJB 1.0.1 or 1.1, to take advantage of bugfixes
>>>>> or
>>>>> performance improvements. But if my application uses a method that
>>>>> is in 1.0, and that method has disappeared in 1.1, the user ends
>>>>> up
>>>>> with a broken system. Such breakage should only happen at major
>>>>> version upgrades. 0.99 -> 1.0 is major, but 1.0 -> 1.0.1 is not.
>>>>>
>>>>>
>>>>> Erik Forkalsrud
>>>>> erik@cj.com
>>>>>
>>>>>
>>>>> Armin Waibel wrote:
>>>>>
>>>>>
>>>>>> Brian McCallister wrote:
>>>>>>
>>>>>>
>>>>>>> -1
>>>>>>>
>>>>>>> RC stage is too late to remove methods. We can get rid of them
>>>>>>> with
>>>>>>> 1.1 or even 1.0.1 if we are in a big hurry, though 1.0.1 should
>>>>>>> only be a bug fix release
>>>>>>>
>>>>>>
>>>>>> hmm (maybe I was too enthusiastic ;-)), I revise my vote, if
>>>>>> deprecated methods works well I agree with Brian.
>>>>>> Armin
>>>>>>
>>>>>>
>>>>>>> -Brian
>>>>>>>
>>>>>>> On Feb 13, 2004, at 12:12 PM, Armin Waibel wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jakob Braeuchi wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> hi all,
>>>>>>>>> Criteria contains some deprecated methods dealing with orderBy
>>>>>>>>> and groupBy. these methods have been moved to query a long
>>>>>>>>> time
>>>
>>> ago.
>>>
>>>>>>>>> what about deleting those methods _before_ releasing 1.0 ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> +1, kick the old stuff out ;-)
>>>>>>>>
>>>>>>>> Armin
>>>>>>>>
>>>>>>>>
>>>>>>>>> jakob
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>> --
>>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
RE: [OT] RC duration; was Re: API changes in Criteria before Release 1.0
Posted by Larry Streepy <la...@staffmix.com>.
It may be a philosophical difference, but I don't think what's been
happening over the last year is a series of Release Candidates. From my
school of thought, an RC is created when you think you have all the major
functionality in and tested and you are packaging for release. You perform
additional testing and qualification on that RC and produce another RC if
bugs are found and fixed. You continue until all critical bugs are
resolved.
Between RC's is not the time to introduce new functionality. It's a time
for stabilization.
Anyway, it may just be semantics, but OJB has been going through a series of
releases that I would tend to call Early Access points. The functionality
is still undergoing significant change and expansion. There's nothing wrong
with that, I would just tend to call them EA 1 - 5 instead of RC 1 - 5.
In truth, what I'm asking for is a period where major functional additions
come to a halt so the code base can be verified in real use. That will get
us to a solid release.
I probably just started a religious war, which was not my intent.
Thanks.
Larry.
> -----Original Message-----
> From: Brian McCallister [mailto:mccallister@forthillcompany.com]
> Sent: Sunday, February 15, 2004 8:44 AM
> To: OJB Developers List
> Subject: [OT] RC duration; was Re: API changes in Criteria before Release
> 1.0
>
> Have we really been in RC for almost a full year?! That isn't good.
>
> -Brian
>
> On Feb 15, 2004, at 11:31 AM, Jakob Braeuchi wrote:
>
> > hi larry,
> >
> > those methods are deprecated since 11 months between RC1 and RC2.
> > this means we'll have to live with them until 1.1.
> >
> > jakob
> >
> > Larry Streepy wrote:
> >
> >> To me, the question boils down to when the methods were deprecated.
> >> If
> >> there was a real release in which the methods were deprecated, then
> >> in a
> >> subsequent release they can be removed. Now, exactly how many
> >> releases you
> >> wait is a matter of policy and the level of change you expect your
> >> consumers
> >> to deal with.
> >> I don't know when these methods were deprecated. If it was part of
> >> the
> >> string of RC's, then they should not come out in the final 1.0. I
> >> don't
> >> know the history of OJB, so I don't know if there was an "official"
> >> 0.9 or
> >> something that everyone considered a true release of the product. If
> >> there
> >> was such a beast, and the methods were deprecated in that release,
> >> then it
> >> would be reasonable to remove them in the 1.0 final release.
> >> This may be open source, but people depend on these API's to
> >> implement real
> >> products. Thus, you need to treat OJB with the same level of care and
> >> provide a reasonable level of stability in the API. It's just good
> >> product
> >> management.
> >> Thanks.
> >> Larry.
> >>> -----Original Message-----
> >>> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
> >>> Sent: Sunday, February 15, 2004 6:16 AM
> >>> To: OJB Developers List
> >>> Subject: Re: API changes in Criteria before Release 1.0
> >>>
> >>> hi brian, erik,
> >>>
> >>>
> >>> Brian McCallister wrote:
> >>>
> >>>
> >>>> Anything marked as deprecated in 1.0 should have an expectation of
> >>>> removal in 1.1
> >>>>
> >>>> I agree that 1.01 should not have client API changes.
> >>>>
> >>>
> >>> that's exactly why i wanted to remove it _before_ 1.0.
> >>>
> >>> jakob
> >>>
> >>>
> >>>> -Brian
> >>>>
> >>>>
> >>>> On Feb 13, 2004, at 7:39 PM, Erik Forkalsrud wrote:
> >>>>
> >>>>
> >>>>> I don't consider myself an OJB developer, so feel free to ignore
> >>>>> this, but I must say that I disagree with the reasoning here.
> >>>>>
> >>>>> If the 1.0 release is going to mean anything at all, I would expect
> >>>>> it to mean API stability, so all API changes like this should go
> >>>>> in
> >>>>> before 1.0 final, or wait until 2.0. If I build an application
> >>>>> that
> >>>>> uses OJB 1.0, any user of that application shouldn't need to worry
> >>>>> about upgrading to OJB 1.0.1 or 1.1, to take advantage of bugfixes
> >>>>> or
> >>>>> performance improvements. But if my application uses a method that
> >>>>> is in 1.0, and that method has disappeared in 1.1, the user ends
> >>>>> up
> >>>>> with a broken system. Such breakage should only happen at major
> >>>>> version upgrades. 0.99 -> 1.0 is major, but 1.0 -> 1.0.1 is not.
> >>>>>
> >>>>>
> >>>>> Erik Forkalsrud
> >>>>> erik@cj.com
> >>>>>
> >>>>>
> >>>>> Armin Waibel wrote:
> >>>>>
> >>>>>
> >>>>>> Brian McCallister wrote:
> >>>>>>
> >>>>>>
> >>>>>>> -1
> >>>>>>>
> >>>>>>> RC stage is too late to remove methods. We can get rid of them
> >>>>>>> with
> >>>>>>> 1.1 or even 1.0.1 if we are in a big hurry, though 1.0.1 should
> >>>>>>> only be a bug fix release
> >>>>>>>
> >>>>>>
> >>>>>> hmm (maybe I was too enthusiastic ;-)), I revise my vote, if
> >>>>>> deprecated methods works well I agree with Brian.
> >>>>>> Armin
> >>>>>>
> >>>>>>
> >>>>>>> -Brian
> >>>>>>>
> >>>>>>> On Feb 13, 2004, at 12:12 PM, Armin Waibel wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Jakob Braeuchi wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> hi all,
> >>>>>>>>> Criteria contains some deprecated methods dealing with orderBy
> >>>>>>>>> and groupBy. these methods have been moved to query a long
> >>>>>>>>> time
> >>>
> >>> ago.
> >>>
> >>>>>>>>> what about deleting those methods _before_ releasing 1.0 ?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> +1, kick the old stuff out ;-)
> >>>>>>>>
> >>>>>>>> Armin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org