Hi All: I see two lines of usage IRL from people:
- I use whatever is "released" on Maven Central. I quote the word released since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and -betas. - I am not allowed to use alpha, beta, or SNAPSHOT versions. The reality ends up being that you see some stacks that have a mix of both of the above. We all know that Jar hell is created when breaking BC within the same package name (and Maven coordinates.) We have clear rules of engagement of major, minor and maintenance releases. The question for me is how should we treat other kinds of releases: alphas and betas. This is assuming that we want to keep on releasing alphas and betas. Jar hell is, well, hellish. I like to avoid it. Since the very nature of alphas and betas is that changing APIs should be allowed, even encouraged in order to get the API in the right shape before a x.y.z release, I am warming to using alpha and beta in package names... If you are to be so bold as to use such a thing, then reflecting that in the import states what you are doing clearly, and avoid any jar hell. That said, it should be left to each component to decide whether or not to opt in such naming. Gary On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski <gillese...@gmail.com> wrote: > 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 > >
