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 <[email protected]>: > 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 >
