On Sun, Jun 5, 2016 at 4:46 PM, Oliver Heger <oliver.he...@oliver-heger.de> wrote:
> Take BCEL as an example. There was a strong momentum about half a year > or so ago to push out a new major release breaking BC. Then discussion > started to revert breaking changes. This would of course have been the > ideal solution for all users: getting a new version without migration > effort. However, the result was that work on reverting changes started, > but was never finished. The momentum vanished, and the release is still > overdue. So would it has been better to break BC in this case? I tend to > say yes. I don't think that example is very helpful. At least, I don't know how anyone should have foreseen the outcome. > Or let's discuss another component: [lang]. The last major release > happened about 5 years ago. In software business these are ages. So > would it make sense to start working on a new version focusing on Java 8 > and better support for Lambdas? We could at least start something in an > experimental branch or the sandbox to experiment with new functionality. > But it is obviously not our style to do this. In that case, i'd strongly be in favour of a new release branch (no need for sandbox) with all the incompatible changes, and a release out of that branch. As long, as the old branch remains available for minor maintenance issues. Jochen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
