> -----Original Message-----
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 24, 2001 11:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [vote]2.x release
>
>
> On 7/24/01 2:13 PM, "Fedor Karpelevitch"
> <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >> Sent: Tuesday, July 24, 2001 10:13 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: [vote]2.x release
> >>
> >>
> >> situation:
> >> there are many bug-fixes in cvs which should land in a 2.x release.
> >> on the other hand some stuff (castor, freemarker, ...) should
> >> be deprecated in
> >> 2.x to follow our deprecation rules (or we must add all the
> >> stuff to 3.0 :-( )
> >>
> >> options:
> >> A) a 2.1.1 release with all the bug-fixes without deprecation
> >> + a 2.2 release
> >> with deprecations (doesn't make sense, does it??)
> >
> > -1
> >
> >>
> >> B) a 2.2 release with bugfixes + deprecations
> >> there will be no api changes in 2.2 only deprecations -> all
> >> 2.1 apps would work
> >> fine, but their might be some warnings at compile time
> >
> > -1
> >
> > it's not "fine" to have "some warning"
> > it's just wrong to do it like that.
> >
> > 2.1.1 (or call it 2.2 - i do not care but prefer 2.1.1) should be a
> > bugfix-only
> >
> > a deprecation release by itself makes no sense so the options are:
> >
> > 1) include the deprecated stuff into 3.0 (i guess you do
> not like that)
>
> In some cases this just won't be possible with the changes
> made. I think
> it is perfectly acceptable to change the API across major versions.
>
> > 2) change DP or make an exception in this case and simply
> drop the staff
> > without deprecation. (this is harsh but seems to be the
> most viable and ok
> > for RL according to the claims that no one was using that
> stuff anyway)
>
> I think this is ok as long as the migration process is well documented
> which I plan to be the case.
so i'm voting for this. (+1)
basically we have three options:
1) f**k up 2.x by putting in deprecation
2) f**k up 3.x by integrating all the old stuff
3) f**k up deprecation policy
i choose 3) ass least harmful.
fedor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
