I'm +1 for moving forward, but I would rather change the package name rather than break backward compatibility. There are a lot of libraries out there that depend on commons-* and you may need older versions on your classpath to get them to work.
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <[EMAIL PROTECTED]> wrote: > Hi all, > non binding +1 for moving to new versions supporting JDK 5 features, > even if breaking compatibility with older versions and rewriting APIs. > There is a lack of good libraries like lang, beanutils etc.. in the > post-1.5 jdks (see the recent thread i participated in regarding > generics), and many projects are dealing with problems with generics, > enums and so on. > > Simone > > James Carman wrote: >> Matt, good idea to revive this. Commons needs to come to grips with >> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even >> support it yet! We need to come up with an approach to this package >> renaming issue and just move forward. >> >> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <[EMAIL PROTECTED]> wrote: >> >>> 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] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Simone Gianni CEO Semeru s.r.l. Apache Committer > MALE human being programming a computer http://www.simonegianni.it/ > > > --------------------------------------------------------------------- > 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]
