You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2011/08/23 04:32:05 UTC
[codec] next releases
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?
Thank you,
Gary
--
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [codec] next releases
Posted by Julius Davies <ju...@gmail.com>.
+1 to 1.6
Julius
On Tue, Aug 23, 2011 at 2:36 AM, Matthew Pocock
<tu...@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 <si...@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 <se...@gmail.com> wrote:
>> > On 23 August 2011 03:32, Gary Gregory <ga...@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
Re: [codec] next releases
Posted by Matthew Pocock <tu...@gmail.com>.
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 <si...@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 <se...@gmail.com> wrote:
> > On 23 August 2011 03:32, Gary Gregory <ga...@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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhamster@gmail.com
gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143
Re: [codec] next releases
Posted by Simone Tripodi <si...@apache.org>.
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 <se...@gmail.com> wrote:
> On 23 August 2011 03:32, Gary Gregory <ga...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] next releases
Posted by sebb <se...@gmail.com>.
On 23 August 2011 03:32, Gary Gregory <ga...@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