Resurrecting this thread from 3.5 months ago as my
itch is returning:
--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
> <[EMAIL PROTECTED]> wrote:
> >> On 12/06/2008, James Carman
> <[EMAIL PROTECTED]> wrote:
> >>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>>
> >>> <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>> >> Do you mean that the removal of the enums
> would mean that we have to
> >>> >> change package names?
> >>> >>
> >>> >> Would class/interface removals necessitate a
> >>> >> package name change? I haven't really
> thought that through.
> >>> >
> >>> > Perhaps not, neither had I
> >>> >
> >>
> >> Removal of a *public* interface/method/class
> means that the API is not
> >> compatible, as it is not possible to replace the
> jar without breaking
> >> classes that use these items.
> >
> > I think we need to make a final decision on this.
> >
> > There seems little argument against moving to 1.5
> in theory. And no
> > one is concerned with using 1.5 features in new
> development. The one
> > open question is: "Should we rename the package"?
> >
> > * If we goto 1.5, we have to remove the enum
> package. It's been
> > deprecated for a good while and a source code fix
> is very easy. Any
> > client that is 1.5 based has had to remove it
> already.
> >
> > * We have a handful of other deprecated methods
> that we've said will
> > be removed in 3.0. We've removed methods in the
> past (I'm pretty sure
> > we did that for 2.0).
> >
> > I'm 50/50 right now. On the one hand, yes I think
> we should remove
> > things and it's not a major version problem. If
> people are having pain
> > it would be very easy to build a separate jar with
> the deprecated
> > methods. However.... if we are going to start
> writing new generics
> > code etc, it is going to be impossible to manage
> to keep that separate
> > from the existing code. How will people know what
> to code where?
> >
> > In which case I think we should just dive right
> into LangTwo now. svn
> > cp the trunk to a branch for maintenance, and
> release of the current
> > bugfixes if we ever need to, and start a new
> LangTwo on the current
> > trunk.
>
> *If* lang2 breaks compatibility, then IMO we should
> use a new package
> name, but moving to JDK 1.5 minimum doesn't
> necessarily dictate that
> (assuming that we release a compatibility jar for
> the enum package
> which has to be removed). IMO it would be better to
> go through putting
> in the JDK 1.5 features that don't break
> compatibility and building up
> a list of possible changes that do. Then we make the
> decision on
> whether compatibility-breaking features seem worth
> it. If it is, then
> lets go all the way, remove deprecations, change the
> package name and
> put them in. If not, then lets leave the package
> name and
> deprecations. We've had a similar discussion over
> Commons IO and IMO
> so far nothing has come up that seems worth the
> whole sale package
> name change - so I think making the decision first,
> without any JDK
> 1.5+ features on the table for consideration is a
> mistake.
Let's see, adding generics shouldn't break
compatibility; would varargs? Beyond that anything
_added_ doesn't break compatibility because we're
talking about existing code with drop-in jar
replacement, right? Have I correctly outlined the
differences between breaking and non-breaking changes
in this context? If so, I'd like to go ahead and
start with the plan. More likely I've missed
something; let's flush it out.
-Matt
>
> Niall
>
> > Gump btw is going to go mad :) It'll think we're
> breaking compatibility.
> >
> > Hen
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
