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 <gil...@harfang.homelinux.org> 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 <seb...@gmail.com> 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 <brit...@apache.org> > >> 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 <gil...@harfang.homelinux.org> > >> 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
