Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a écrit : > > I’m having a hard time understanding the comparing APIs use case. If I > were to want to try that, I’d create a branch and import the new dependency > version and see what breaks. The performance part I wouldn’t think I’d use > one code base either. I’m not suggesting my way is the only or best way, > just explaining why I’m having a hard time understanding what you’re > doing. Maybe this will be a learning opportunity for me! :)
Case mainly in point is getting to the first release of new components. This is happening now for [Imaging], and will be soon (hopefully) for [Numbers], [Statistics] and [Geometry]. IIUC, the former is going to release a beta version without modifying the top-level package name. This will create the possibility of JAR hell (when 1.0 will be out). Since we don't have that much review/feedback on these new and/or refactored codes, I thought we could be on a safer ground if we first release beta version(s) that * won't be subject to JAR hell and * will be easy (i.e. just add the dependency in the POM file) to integrate for people kind enough to give it a try. [If it's not easy[1], they won't do it.] Regards, Gilles [1] Like: You "just" have to install "git", check out the source, install "maven", run the "package" goal, then move the "target/whatever.jar" file to where your code will look for it. > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a > > écrit : > > > > > > What sort of comparison are you looking to do within the same code? > > > Performance? > > > > Yes, that's one possibility; another is comparing different APIs. > > > > Gilles > > > > >>>> [...] > > > > --------------------------------------------------------------------- > > 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
