Hi.
On Thu, 17 May 2018 10:28:05 -0600, Gary Gregory wrote:
Hi All,
Note that strictly speaking, we only publish source code. Binary
files like
jar files are only provided as a convenience. Apache Subversion, for
example, leaves binary production and distribution to third parties.
So a "partial release" would mean a "partial release" of sources, as
opposed to a full release of sources and a partial release of
binaries. I
am sure you could rejigger the POM and assemblies to produce the a
source
zip that would amount to a "partial release." I am not sure it is
worth the
complication though, YMMV.
Sorry, but I'm missing something if there is any complication
involved in what I called "partial release": It is dead simple to
delete, from the *release branch*, all sources not to be released!
The KISS approach would be to release it all with an alpha or beta
label.
No, that is actually more complicated from the marketing POV: we'd
have to explain why some of the codes are "not really beta" while
others are "almost stable" and still others are "alpha"...
Many false impressions will be conveyed.
It will also be a pain with the CLIRR/japicmp reports.
You could go as far as repackaging the code with a "0" package name
post
fix for an alpha or beta if BC is a real concern.
"0" or "experimental"?
I'd rather have the latter.
Note that I asked about BC of all pre-1.0 releases; if they must be
BC compatible, then I don't see the gain (of going "experimental"):
It will be a PITA for users who'd want to help by trying the code,
since they would need to change their code at every 0.x release!
So IMO it's either
* release everything (RERO) with no BC constraints in 0.x, or
* release only issue-free codes as 1.0
Which one will it be?
Gilles
Gary
On Thu, May 17, 2018 at 6:02 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hi.
I only got one response to my previous question about
a "partial" release of the code currently in [Numbers],
which was to make a "beta" release.
I guess that it meant an "experimental" release of
*everything* even of code with known issues (big or
small).
The first release would be e.g. version 0.5 and all
releases below 1.0 could be BC-breaking.
Then in each release above 1.0, we'd decide which codes
would be lifted from the "experimental" package.
Is that correct?
If not, please state exactly what you'd want to be done
for getting your vote on a release candidate.
If we go the "experimental" way, I'd like other useful
modules to be added to [Numbers]:
* commons-numbers-rootsolver (with codes from package
"org.apache.commons.math4.analysis.solver")
* commons-numbers-quadrature (with codes from package
"org.apache.commons.math4.analysis.integration")
* commons-numbers-interpolator (with codes from package
"org.apache.commons.math4.analysis.interpolation")
* commons-numbers-polynomial (with codes from package
"org.apache.commons.math4.analysis.polynomials")
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
