I only mentioned starting at 1.0 again because I saw "Commons Lang Two 1.0" listed in JIRA. It makes sense to me, although it is very awkward to digest. :-) That's why I would rather advocate IO 2.0 keeping the same package naming. No binary compatibility is guaranteed between major releases anyway.
Struts 2 chose a different package structure so that previous code (1.x) can run side-by-side with the new product. If Commons IO can state that intention, then having a new package structure has justification. Paul On Feb 6, 2008 10:04 AM, James Carman <[EMAIL PROTECTED]> wrote: > On 2/6/08, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Niall, I agree as well. I don't see a strong reason for keeping any > > deprecations if the package structure is changing. It is no longer > binary > > compatible -- especially if you begin at version 1.0 again. > > Version 1.0? So, it'd be org.apache.commons.io2, but the release > would be version 1.0? I don't know about that. I'd think that > anything packaged in io2 packages would be released under a 2.x > release number. > > > > > Paul > > > > On Feb 6, 2008 9:46 AM, Niall Pemberton <[EMAIL PROTECTED]> > wrote: > > > > > On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> > wrote: > > > > ---- Stephen Colebourne <[EMAIL PROTECTED]> schrieb: > > > > > Deprecation is useful when a method has been > > > > > implemented incorrectly, and we want to push users > > > > > to a replacement, or for similar issues. Removing deprecated > > > > > classes/methods should be considered in a major version change, > > > > > but even there we should question what the gain is. Having a > > > > > 'nice and clean' no deprecations API release isn't sufficient a > > > > > reason. We must always put the convenience of our users ahead of > > > > > our natural refactoring and coding instincts. > > > > > > > > +1 > > > > > > > > If a deprecated method is blocking significant improvement of the > > > product, then ok remove it. But just to "clean up" is not really a > good > > > enough excuse. > > > > > > I don't mind the deprecations staying for IO 2.x - just thought that > > > if there was going to be a package rename for JDK 1.5, then may as > > > well clean up the deprecations as well. If, because of generic erasure > > > IO 2.x isn't incompatible (except for the requirement for a higher JDK > > > version) then how about retaining the current package name? > > > > > > Niall > > > > > > > > The problem is that there is no practical solution to a jar > > > > > hell situation. Thus, it is our absolute responsibility to > > > > > do everything in our power to avoid us being the cause of it. > > > > > > > > Over the last two weeks I've been working on embedding jspwiki into > a > > > locally developed application. Now jspwiki is compiled against Lucene > > > 1.4.3, but the app already uses Lucene 2.3.0. And yep, they are > > > incompatible (slightly, but enough). > > > > > > > > Fortunately jspwiki's search functionality is "pluggable" so by > > > rewriting one jspwiki class I could make things work. But if the > problem > > > library had been more deeply embedded into the two systems I don't > know what > > > I could possibly have done. > > > > > > > > Of course if the new release was org.apache.lucene2, then there > would be > > > no problem. > > > > > > > > Compatibility is important. > > > > > > > > Regards, Simon > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > >
