On 8 April 2013 08:14, Luc Maisonobe <luc.maison...@free.fr> wrote: > 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 ... >
Might be a good time to re-organise the code into external and internal classes. Ideally one would use public/protected vs. package/private for that, but that's not always possible with Java. But so long as a class is clearly marked as being internal to Math, I think it's OK for the API to change at will - just as would be the case for changing the signtaure of a private or package method in any class. > 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 > >
