Hi all guys, I'd suggest to go through 1.6 too, even if we have a precedence in the past (before I joined as committer) when the Digester version was promoted from 1.8 to 2.0 just switching to JVM and added Generics... So my "concern" is just make sure we adopt a common policy for every component and understand if the Digester case was just an exception (or not). Have a nice day, all the best!!! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 23, 2011 at 4:42 AM, sebb <seb...@gmail.com> wrote: > On 23 August 2011 03:32, Gary Gregory <garydgreg...@gmail.com> wrote: >> Hi All: >> >> After the last round of discussion WRT generics, a 2.0, version, and the new >> BM encoder, it seems the consensus is: >> >> - Release a version based on trunk. Trunk requires Java 5 and includes the >> new BM encoder. >> >> - Revert the trunk changes that break binary compatibility, specifically, >> based on Clirr: >> >> Severity Message Class Method / Field >> Error Method 'public StringEncoderComparator()' has been removed >> org.apache.commons.codec.StringEncoderComparator public >> StringEncoderComparator() >> Error Method 'public boolean isArrayByteBase64(byte[])' has been >> removed org.apache.commons.codec.binary.Base64 public boolean >> isArrayByteBase64(byte[]) >> Error Class org.apache.commons.codec.language.Caverphone removed >> org.apache.commons.codec.language.Caverphone >> Error Method 'public int getMaxLength()' has been removed >> org.apache.commons.codec.language.Soundex public int getMaxLength() >> Error Method 'public void setMaxLength(int)' has been removed >> org.apache.commons.codec.language.Soundex public void setMaxLength(int) >> Error Field charset is now final >> org.apache.commons.codec.net.URLCodec charset >> Error Method 'public java.lang.String getEncoding()' has been removed >> org.apache.commons.codec.net.URLCodec public java.lang.String >> getEncoding() >> >> - Continue the generics discussion toward a major release which would likely >> require a package name change. >> >> Question: Because the code now requires Java 5, should the new version be >> 1.6 or 2.0? >> >> 1.6 feels right because we are adding an encoder. >> The only reason now for a 2.0 label is because we are using Java 5. >> >> Thoughts? > > A major version bump is required for API breaks; it is not required > for changes in base Java level. [1] > > Though if we were suddenly to require Java 7 it might make sense to go to 2.0. > > Given that Java 1.5 has been out for some years now, and most users > will probably be on at least Java 1.5 now, it seems to me that it's > not necessary to have a major version bump; 1.6 is fine by me. > > [1] http://commons.apache.org/releases/versioning.html > >> Thank you, >> Gary >> -- >> http://garygregory.wordpress.com/ >> http://garygregory.com/ >> http://people.apache.org/~ggregory/ >> http://twitter.com/GaryGregory >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
