You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@joda.org> on 2018/08/30 18:28:37 UTC
Re: [Math] Beta release (Was: [All] What's in a "beta" release?)
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 <gi...@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 <se...@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 <br...@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 <
> >> > garydgregory@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 <gi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Beta release
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Thu, 30 Aug 2018 19:28:37 +0100, Stephen Colebourne wrote:
> What I would love to see it a release of commons-math 3
Is it usual to release an unsupported codebase?
If yes, is there someone willing to work on this?
> with an
> Automatic-Module-Name for Java 9 modules (potentially the only
> change).
A v3.6.1.1 thus?
> You could use the release as a way of advertising the
> progress towards v4.
Fine to write a paragraph in the release notes; but I'm not so
sure that it would change anything to the current situation.
What incentive will people still using v3.6.1 (or lower) have
for using v4.0-beta (or contribute to get to v4.0)?
Gilles
> Stephen
>
>
> On Thu, 30 Aug 2018 at 19:16, Gilles <gi...@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 <se...@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 <br...@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 <
>> >> > garydgregory@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
>> <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org