In the past we have only guarded against jar-hell with major component releases matching a package name changes and Maven coordinate name change.
It seems some want to apply the same principles to other kinds of versions, not just major version. Like a 0.9.alpha1 or even a 2.0.beta-1. I suppose there is nothing stopping us from that... Gary On Wed, Jun 5, 2019 at 12:16 PM 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). > > 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 > >