+1 to all of the below.
The lesson from Lang imo is to charge in and just do it. It'll
generate ideas once people are free to consider backwards incompatible
changes. Rolling back is always possible if we decide we didn't really
justify a 2.0.
Look at what else is out there. Is the scope of Codec
On Sun, Apr 3, 2011 at 9:35 PM, Gary Gregory wrote:
> What about dropping deprecated items? That should be OK in a 2.0. I was
> planning on doing that today.
>
> That does not preserve drop-in reverse compatibility but we do it in major
> releases.
First step to binary incompatibility, which I s
On 3 April 2011 20:35, Gary Gregory wrote:
> On Fri, Apr 1, 2011 at 2:50 AM, Jörg Schaible
> wrote:
>
>> Julius Davies wrote:
>>
>> >>> >> Nothing of this (including minimum requirement of Java 5) requires
>> >>> >> automatically 2.x. As long as the API is *upward* binary compatible,
>> >>> >> you
On Fri, Apr 1, 2011 at 2:50 AM, Jörg Schaible
wrote:
> Julius Davies wrote:
>
> >>> >> Nothing of this (including minimum requirement of Java 5) requires
> >>> >> automatically 2.x. As long as the API is *upward* binary compatible,
> >>> >> you can
> >>> >> improve the implementation using this fe
Julius Davies wrote:
>>> >> Nothing of this (including minimum requirement of Java 5) requires
>>> >> automatically 2.x. As long as the API is *upward* binary compatible,
>>> >> you can
>>> >> improve the implementation using this features, adding new methods or
>>> new
>>> >> classes. Even generi
>> >> Nothing of this (including minimum requirement of Java 5) requires
>> >> automatically 2.x. As long as the API is *upward* binary compatible, you
>> >> can
>> >> improve the implementation using this features, adding new methods or
>> new
>> >> classes. Even generics can be added to some exte
On Thu, Mar 31, 2011 at 9:36 PM, sebb wrote:
> On 1 April 2011 01:40, Gary Gregory wrote:
> > On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible >wrote:
> >
> >> Hi Jochen,
> >>
> >> Jochen Wiedmann wrote:
> >>
> >> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies <
> juliusdav...@gmail.com>
> >> >
On 1 April 2011 01:40, Gary Gregory wrote:
> On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible wrote:
>
>> Hi Jochen,
>>
>> Jochen Wiedmann wrote:
>>
>> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies
>> > wrote:
>> >
>> >> I'm confused. We support streaming for Base64 since codec-1.4 (and
>> >> n
On Thu, Mar 31, 2011 at 5:12 PM, Jörg Schaible wrote:
> Hi Jochen,
>
> Jochen Wiedmann wrote:
>
> > On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies
> > wrote:
> >
> >> I'm confused. We support streaming for Base64 since codec-1.4 (and
> >> now Base32 since codec-1.5). You committed the Base64Inp
Hi Jochen,
Jochen Wiedmann wrote:
> On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies
> wrote:
>
>> I'm confused. We support streaming for Base64 since codec-1.4 (and
>> now Base32 since codec-1.5). You committed the Base64InputStream
>> patch, Jochen!
>>
>> https://issues.apache.org/jira/browse
On Thu, Mar 31, 2011 at 9:23 PM, Julius Davies wrote:
> I'm confused. We support streaming for Base64 since codec-1.4 (and
> now Base32 since codec-1.5). You committed the Base64InputStream
> patch, Jochen!
>
> https://issues.apache.org/jira/browse/CODEC-69
>
> Is there other streaming you woul
On Thu, Mar 31, 2011 at 3:23 PM, Julius Davies wrote:
> On Wed, Mar 30, 2011 at 4:28 PM, sebb wrote:
> > On 31 March 2011 00:17, Jochen Wiedmann
> wrote:
> >> On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote:
> >>
> >>> But does the API have to change, or could these additional features be
> >>> sup
On Wed, Mar 30, 2011 at 4:28 PM, sebb wrote:
> On 31 March 2011 00:17, Jochen Wiedmann wrote:
>> On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote:
>>
>>> But does the API have to change, or could these additional features be
>>> supported by adding new methods and classes?
>>
>> Not necessarily. But
On 31 March 2011 00:17, Jochen Wiedmann wrote:
> On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote:
>
>> But does the API have to change, or could these additional features be
>> supported by adding new methods and classes?
>
> Not necessarily. But my point is that codec is in a state where
> breaking
On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote:
> But does the API have to change, or could these additional features be
> supported by adding new methods and classes?
Not necessarily. But my point is that codec is in a state where
breaking the API will make work just easier. So why not take the
op
On 30 March 2011 16:19, Jochen Wiedmann wrote:
> On Tue, Mar 29, 2011 at 8:52 PM, sebb wrote:
>
>> I think that should be avoided unless the API is also being changed in
>> an incompatible way, and then only if it really is impossible to
>> maintain backwards compatibility.
>
> I think there are
On Tue, Mar 29, 2011 at 8:52 PM, sebb wrote:
> I think that should be avoided unless the API is also being changed in
> an incompatible way, and then only if it really is impossible to
> maintain backwards compatibility.
I think there are excellent reasons to change the API in codec.
Reasons inc
sebb wrote:
> On 29 March 2011 18:44, Gary Gregory wrote:
>> Hi All,
>>
>> Now that codec 1.5 is out, I would like thoughts on this plan for codec
>> 2.0:
>>
>> - Create a SVN branch for 1.x
>>
>> Then in trunk:
>> - Correct Maven group id, which implies:
>
> -1, see below.
>
>> - Repackage to
On Tue, Mar 29, 2011 at 2:52 PM, sebb wrote:
> On 29 March 2011 18:44, Gary Gregory wrote:
> > Hi All,
> >
> > Now that codec 1.5 is out, I would like thoughts on this plan for codec
> 2.0:
> >
> > - Create a SVN branch for 1.x
> >
> > Then in trunk:
> > - Correct Maven group id, which implies:
On 29 March 2011 18:44, Gary Gregory wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
> - Create a SVN branch for 1.x
>
> Then in trunk:
> - Correct Maven group id, which implies:
-1, see below.
> - Repackage to o.a.c.codec2
This forces all end
+1 for me Gary, I strongly support this kind of initiatives!!!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 29, 2011 at 7:44 PM, Gary Gregory wrote:
> Hi All,
>
> Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
>
Hi All,
Now that codec 1.5 is out, I would like thoughts on this plan for codec 2.0:
- Create a SVN branch for 1.x
Then in trunk:
- Correct Maven group id, which implies:
- Repackage to o.a.c.codec2
- Use Java 5
- Use JUnit 4
What else? Thoughts?
Thank you,
Gary
--
http://garygregory.wordpress
22 matches
Mail list logo
