commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <juliusdav...@gmail.com>
Subject Re: [codec] next releases
Date Wed, 24 Aug 2011 17:16:59 GMT
+1 to 1.6

Julius

On Tue, Aug 23, 2011 at 2:36 AM, Matthew Pocock
<turingatemyhamster@gmail.com> wrote:
> My vote (not that I have one) would be for 1.6, and to keep 2.0 as the
> release when the breaking changes are introduced.
>
> Matthew
>
> On 23 August 2011 09:18, Simone Tripodi <simonetripodi@apache.org> wrote:
>
>> 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 <sebbaz@gmail.com> wrote:
>> > On 23 August 2011 03:32, Gary Gregory <garydgregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message