On June 5, 2019 at 12:16:33, Gilles Sadowski (gillese...@gmail.com) wrote: 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). Sounds like the issue is doing ‘alpha’ and ‘beta’ releases instead of just using versioning. 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
