Hi Gary (and Sebb who had similar concerns), Le 08/04/2013 00:33, Gary Gregory a écrit : > I would only go back and bother with creating a branch when it is > needed. As for a repackage I would only do that if I knew for certain > that I want to break BC.
Yes, we need (not want) to break compatibility. This is the reason we had to postpone several issues. These issues change API. Typical examples are removing packages, removing classes, removing user public methods, changing method signatures, puching methods upwards from classes to interfaces, changing interfaces ... Luc > > Gary > > On Apr 7, 2013, at 8:57, Luc Maisonobe <l...@spaceroots.org> wrote: > >> Hi all, >> >> The release for 3.2 has been completed. Now it is time to think about >> the next release. >> >> There are many JIRA issues that target 4.0 as they need to introduce >> backward incompatible changes. All these changes would be really welcome. >> >> I suggest we create a 3.x branch just in case we need to fix something >> and make another release, either 3.2.1 or 3.3, but otherwise focus on >> 4.0. >> >> In this case, we should probably change the top level package to math4 >> immediately, so it would allow all users to have both the new and the >> old library in the same application, so they can both use the new >> features we will introduce while having some time to remove their >> dependency to the features we will change. >> >> What do you think about this proposal? >> >> best regards, >> Luc >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
