james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: 0.6.2 or 0.7 any time soon? was Re: Incorrect line length limitation while parsing headers
Date Tue, 11 Jan 2011 13:01:55 GMT
2011/1/11 Oleg Kalnichevski <olegk@apache.org>:
> On Tue, 2011-01-11 at 09:27 +0100, Norman Maurer wrote:
>> Hi there,
>>
>> I think if it worth it we should release 0.6.2. Release often release
>> early, you know ;)
>>
>> Bye,
>> Norman
>>
>
> Folks
>
> I also would like to port another fix, should we decide to do another
> release off the 0.6.x branch.

What is the other fix? This one is not critical (I see it just like a
documentation bug: either way we need that check on that field to work
that way, we can't simply check the line length).

> I am also willing to make a push toward the 0.7 release, if no one is
> going to pick up work on the API changes stared by Stefano on the trunk.

I had really few time but I think I also slowed down because I never
understood if what I was doing was liked or not. It takes a lot to
complete stuff, so I would have liked to understand what others thinks
we should do in 0.7.

As an example I see sometimes we talk as 0.x versions we can do
backward incompatible changes trying to reach a good api, other times
it seems we instead are "stuck" to the 0.6 version because 0.6 has
already a lot of users so compatibility is brought to the table.

That said, I say my opinion and I expect others to say their opinions
so that we can see where we can find a consensus.
- I think 0.6 is not "great" as API, so I would happily break
compatibility in order to provide a better api. Main thing is that the
0.6 API does not accept evolution (every non trivial feature will
require a backward incompatible change).
- IMO current trunk could be released as 0.7.0 with very minor change:
it is far from exposing a complete api, but I find it already better
than 0.6 and I have already some product depending on current trunk.
We saw we proceed at a slow speed, so we should be prepared improving
the API while we reach 1.0.
- I guess most of changes we have in trunk are not backportable to 0.6
because they have been possible by the major refactorings, but I'm not
against this, if anyone sees a way.

Can you state yours and also tell something more about "your" 0.7 plan?

Stefano

Mime
View raw message