james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.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:45:33 GMT
On Tue, 2011-01-11 at 14:01 +0100, Stefano Bagnara wrote:
> 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).

Parsing of folded fields. The default field parser in 0.6 chokes on
perfectly valid fields if their body is folded. 

> > 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?

I think we discussed this on more than one occasion in the past. While I
think mime4j 'core' in 0.7 is fine, the 'dom' / 'message' stuff is not,
and the whole library is not in a releasable state at the moment. 

And there is "my" plan:

(1) ask people to go over issues in JIRA and decide what is in scope for
0.7 and what can wait until a better day (0.8)
(2) revisit the 'dom' and 'message' packages and try to figure out
whether 'model' and 'implementation' classes in their present form make
sense. In my option, many of them do not.


View raw message