Le mer. 5 juin 2019 à 23:14, sebb <seb...@gmail.com> a écrit : > > On Wed, 5 Jun 2019 at 17:16, 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. > > No need to install Git; can just download the source archive and unpack it. > I think we can assume they already have Maven, otherwise why are we > worried about releasing to Maven? > > Note that the suggestion of using different package names will force > users to edit their code.
So what; this is the purpose of beta-testing features that don't exist in previous releases or in the previous beta version. > They will then have to compile their source, probably using Maven. > > Seems to me the suggestion creates more work for end users. People will have to do something. When they raise an issue, it is easier for me and for them to point to one-line change in their dependencies (and the corresponding change in their code), then to start explaining that they should build from source. >From the discussion, I'm still missing the opinion stating explicitly that "we don't care about JAR hell produced by a beta release". My suggestion is only to avoid that. Is the PMC fine releasing *incompatible* beta releases (and of course incompatible with the "stable" release that will follow) with the same package name? Gilles > > > > > > 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
