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

Reply via email to