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: [RFC] Binary compatibility between 0.7 and 0.8?
Date Mon, 13 May 2013 17:56:36 GMT
I'm fine with breaking binary compatibility if we need it to improve
the library.
I'd like to reduce needed changes for source compatibility, but I
don't think we should aim to binary compatibility in a 0.x release.

This apply expecially to DOM APIs having always been experimental and
not widely used (because they have clear limits in the current form).


2013/5/10 Oleg Kalnichevski <olegk@apache.org>:
> Folks
> I have some spare cycles I can invest in mime4j. I am presently going
> through test cases, cleaning them up, and also making (fairly) minor
> changes to core classes that do not affect binary compatibility with the
> 0.7 branch. At some point, though, I would like to start making more
> fundamental changes that can potentially cause API incompatibility. This
> especially concerns DOM APIs redesign discussed some while ago. Up to
> now we never truly cared about maintaining binary compatibility between
> 0.x releases. This makes our lives as developers easier but makes it
> more difficult for users to upgrade.
> Do we want to adopt a more conservative approach with 0.8 release? The
> only downside to keeping old deprecated classes around is having to
> choose different, often longer and uglier, names for essentially the
> same things. For instance, we will have to pick a different name for
> MessageBuilder if we want to deprecate and keep the old code.
> What do you think?
> Oleg

View raw message