Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
> On 24/03/2020 13:30, Rob Tompkins wrote:
> > Yes you’re totally welcome to, and the directions are here: 
> > http://commons.apache.org/releases/index.html 
> > <http://commons.apache.org/releases/index.html>
> >
> > Feel free to ask questions and I would suggest using the release plugin 
> > portion of the release preparation page. If there’s confusion (I would 
> > expect some obsolescence) on the page do make note of it, and I would be 
> > happy to update it as we see fit.
> >
> > All the best,
> > -Rob
> The [rng] project has a useful release guide for a multi-module project
> (I think partly written by Rob):
>
> doc/release/release.howto.txt

I started it for "Commons Math" when I attempted my first release of it,
and everything available was flawed in one way or another.
It was later modified for git-based development, then copied (mutatis
mutandis) into [RNG].

Part of the release process is nevertheless based on tools initiated
by Rob.  But, last time I tried, there were issues because (AFAICT)
modularity was not fully taken into account.  I don't whether it has
improved (I seem to recall of lingering JIRA reports).

It would certainly be great to consolidate the docs.
At least, components
 * RNG
 * Statistics
 * Numbers
 * Geometry
should behave the same wrt the release process.

>
>
> Q. Is this to be released as a beta?
>
> The commons release page linked indicates the artefacts would be named
>
> commons-numbers-XXX-1.0-B1.jar
>
>
> It does not state anything about changing the package coordinates.

I asked several times for confirmation on this ML: IIRC, conclusion is
that, while in "beta", it is OK
 * to break compatibility, and
 * to cause JAR hell.
[The advantage is that users can drop replacement JARs and see the
effect of changes without touchin their code.]

> Releasing under beta does allow changes as there are "no guarantees of
> stability or maintenance". So this could be released and we can still
> change the API. For instance there is the Complex streams modules that
> is due in part to be dropped and replaced by a ComplexList
> representation of many complex numbers. I hope to get back to working on
> this soon.

Since we know that ComplexUtils will not make to the official release
(because Alex's proposal is convincingly better), I'd remove that module
from the release branch.

Thank ou for stepping up,
Gilles

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to