[RFC] Binary compatibility between 0.7 and 0.8?

[Oleg Kalnichevski <ol...@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

Re: [RFC] Binary compatibility between 0.7 and 0.8?

[Stefano Bagnara <ap...@bago.org>]

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).

Stefano

2013/5/10 Oleg Kalnichevski <ol...@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
>