2011/1/11 Oleg Kalnichevski <[email protected]>: > On Tue, 2011-01-11 at 14:01 +0100, Stefano Bagnara wrote: >> 2011/1/11 Oleg Kalnichevski <[email protected]>: >> > 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,
Yes, we discussed a couple of times, but we didn't find a solution (at least not one I understood) > and the whole library is not in a releasable state at the moment. Got it: hope you will review trunk soon to understand what changes you propose to make it releasable. > 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) +1 The main causes I use trunk in production instead of 0.6 are: MIME4J-158 - Reduce usage of commons-logging in favor of a "Monitor" service. https://issues.apache.org/jira/browse/MIME4J-158 MIME4J-58 - Lenient dealing with headless messages or malformed header/body separation https://issues.apache.org/jira/browse/MIME4J-58 MIME4J-153 - Headless inconsistency between MimeTokenStream and MimeStreamParser https://issues.apache.org/jira/browse/MIME4J-153 Also the folded header stuff you mentioned (MIME4J-141 - MIME4J-146) > (2) revisit the 'dom' and 'message' packages and try to figure out > whether 'model' and 'implementation' classes in their present form make > sense. +1 > In my option, many of them do not. They are the result of my limited use case: they work fine in my use cases (jDKIM + proprietary product). We need more real use cases to "shape" them, but I trust you (and you probably have good uses cases too), so I will wait for your review. Stefano
