OSDir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Numbers] First (partial) release


Executive summary (to the best of my knowledge):

Ready (IMHO) for release ("no known issues"):
 * Module "core"
 * Module "angle"
 * Module "arrays"
 * Class "Complex"

Not to be released:
 * Class "ComplexUtils" (outdated API to be replaced by "streams",
   insufficient coverage, ...)
 * Module "field" (no consensus about API and implementations;
   discussion has been pending for months)

Needs work:
 * Class "Fraction", "BigFraction" (make them "ValJO")
 * Class "Quaternion"

To be reviewed (cf. JIRA) for ensuring API stability:
 * Module "gamma"
 * Module "combinatorics"
 * Module "primes"

Volunteers?

I'm OK with releasing with an "experimental" prefix (all packages
under "org.apache.commons.numbers.experimental"); do we agree that
JAR hell is allowed in those (i.e. non need to have "experimental2",
"experimental3" when BC is broken)?

Gilles

On Fri, 11 May 2018 02:35:40 +0200, Gilles wrote:
On Thu, 10 May 2018 18:08:13 -0600, Gary Gregory wrote:
On Thu, May 10, 2018 at 5:10 PM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
wrote:

On Thu, 10 May 2018 08:22:40 -0600, Gary Gregory wrote:

How about releasing as "beta" i.e. 1.0-beta1?


It would not reflect the real status.
As noted below, "Complex" is past beta,


Great.


while some of the
other codes need review and/or a little work to settle
known issues.


Sounds like a Beta.

To me "beta" sounds: "No _known_ issues".


Furthermore, I recall that no beta release of a Commons
project ever elicited any feedback.


So what? Getting a jar out on Maven central will give at least the that
opportunity.

Experience tells otherwise (about "beta" release).
But for sure, the intent is that the release would get attention
to the project.

It's better that realizing that you want some BC breaking
changes _after_ a 1.0 is out.

Back to square one: I don't want to release known unfinished
work (cf. JIRA for pending reviews) but do want to release
the supposedly stable code.

Does some policy forbid not releasing some parts of the project?
[Technically, it would be a matter of deleting the unselected
modules from the release branch.]

Gilles


Gary



Gilles


Gary

On Thu, May 10, 2018 at 7:39 AM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
wrote:

Hi.

The modules in [Numbers] are not all in a releasable state;
even if a lot of work has been put in all of them, some
need even more to be on a par with e.g. the "Complex" class.

It doesn't seem to serve any purpose to further delay the
release as there isn't any activity towards resolving the
issues that concerns the other modules.

Thus, I'd like to release "commons-numbers-complex" (without
"ComplexUtils") and its dependencies, as well as a few other
modules which one would expect can be stable in the long run.
Will some people review the modules and afferent issues to
give an opinion on those they'd think would be ready for prime
time?

Thanks,
Gilles




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx