What I would love to see it a release of commons-math 3 with an
Automatic-Module-Name for Java 9 modules (potentially the only
change). You could use the release as a way of advertising the
progress towards v4.
Stephen
On Thu, 30 Aug 2018 at 19:16, Gilles wrote:
>
> On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote:
> > But SNAPSHOT builds _are_ publicly available on
> > repository.apache.org. Sure
> > they come and go and you cannot rely on their permanence.
>
> And, perhaps, developers do not check what's available there...
> Reports keep coming showing that they don't know about the status
> of "Commons Math".
>
> Thus the idea that a beta release might draw to the rejuvenation
> attempt. A "beta" because it is still a lot of work to fix all
> the identified issues and we need extra help; a "release" because
> a lot of work has been done since the last release, providing many
> bug fixes and other improvements.
>
> A release of the development version of CM requires the release
> of its dependencies: "Commons Numbers" and "Commons Statistics".[1]
> Both would be "beta" too.
>
>
> Regards,
> Gilles
>
> [1] And also "Commons Geometry" if the code is in a state that's
> able to replace the "o.a.c.math4.geometry" package.
>
> > Gary
> >
> > On Thu, Aug 30, 2018, 04:50 sebb wrote:
> >
> >> SNAPSHOT builds must only be published to Commons developers.
> >> They cannot be published on public download pages.
> >>
> >> Also they may disappear or be replaced at any time.
> >>
> >> Beta builds are subject to a release VOTE, and so can be published
> >> in
> >> the usual way.
> >> Once published, they are permanently available.
> >>
> >> On 30 August 2018 at 09:38, Benedikt Ritter
> >> wrote:
> >> > What's the difference to a nightly build being published to the
> >> Apache
> >> > Snapshot repo?
> >> >
> >> > Benedikt
> >> >
> >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory <
> >> > garydgreg...@gmail.com>:
> >> >
> >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can
> >> depend
> >> on
> >> >> another beta, for example see HttpComponents. We should not
> >> release a
> >> >> non-beta that depends on a beta. I think breaking BC is to be
> >> expected
> >> in
> >> >> an alpha and less so in a beta. Changing package names and
> >> coordinates
> >> from
> >> >> one beta to the next seems a bit excessive but I would not object
> >> to it.
> >> >>
> >> >> Gary
> >> >>
> >> >> On Wed, Aug 29, 2018, 10:36 Gilles
> >> wrote:
> >> >>
> >> >> > Hello.
> >> >> >
> >> >> > Do you have an idea of what it would take to automate "beta"
> >> >> > releases?
> >> >> > By this I mean: take a component (at some state) and create
> >> >> > a branch (with all the necessary adaptations) to become an
> >> >> > official release.
> >> >> >
> >> >> > Are "beta" releases subject to the same BC requirements as
> >> >> > "ordinary" ones? Concretely, suppose that several releases
> >> >> > will be necessary: Do they have to change top-level package
> >> >> > name?
> >> >> >
> >> >> > Can a (non-"beta") release (of some component) depend on a
> >> >> > "beta" release (of another component)? Or has the former to
> >> >> > be a "beta" too?
> >> >> >
> >> >> > Rationale: I imagine that uploading to "Maven Central" may
> >> >> > help correcting the misrepresentation of resources available
> >> >> > from this project.
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> > 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
