[All] What's in a "beta" release?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[All] What's in a "beta" release?

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

garydgregory
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

Benedikt Ritter-4
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 <
[hidden email]>:

> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

sebb-2-2
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 <[hidden email]> 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 <
> [hidden email]>:
>
>> 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 <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

garydgregory
But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure
they come and go and you cannot rely on their permanence.

Gary

On Thu, Aug 30, 2018, 04:50 sebb <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]>:
> >
> >> 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 <[hidden email]>
> 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: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

[Math] Beta release (Was: [All] What's in a "beta" release?)

Gilles Sadowski
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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>> > [hidden email]>:
>> >
>> >> 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 <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Beta release (Was: [All] What's in a "beta" release?)

jodastephen
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >> 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 <
> >> > [hidden email]>:
> >> >
> >> >> 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 <[hidden email]>
> >> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Beta release

Gilles Sadowski
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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> >> 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 <
>> >> > [hidden email]>:
>> >> >
>> >> >> 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
>> <[hidden email]>
>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

sebb-2-2
In reply to this post by garydgregory
On 30 August 2018 at 15:35, Gary Gregory <[hidden email]> wrote:
> But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure
> they come and go and you cannot rely on their permanence.

Just about all our code is available from URLs that don't require logins.

However only formal releases should be announced to the general public.

Other links should be confined to pages intended for Commons developers

> Gary
>
> On Thu, Aug 30, 2018, 04:50 sebb <[hidden email]> 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 <[hidden email]> 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 <
>> > [hidden email]>:
>> >
>> >> 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 <[hidden email]>
>> 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: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

Benedikt Ritter-4
This discussion keeps popping up every few month. At the end we alway
conclude that we don't want to publish anything that's binary incompatible
under the same coordinates. So way are we discussing this again? Appending
"beta" to a release version will not stop people from using it. So why not
simply call it 1.0 and be done with it?

Benedikt

Am Fr., 31. Aug. 2018 um 01:30 Uhr schrieb sebb <[hidden email]>:

> On 30 August 2018 at 15:35, Gary Gregory <[hidden email]> wrote:
> > But SNAPSHOT builds _are_ publicly available on repository.apache.org.
> Sure
> > they come and go and you cannot rely on their permanence.
>
> Just about all our code is available from URLs that don't require logins.
>
> However only formal releases should be announced to the general public.
>
> Other links should be confined to pages intended for Commons developers
>
> > Gary
> >
> > On Thu, Aug 30, 2018, 04:50 sebb <[hidden email]> 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 <[hidden email]> 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 <
> >> > [hidden email]>:
> >> >
> >> >> 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 <[hidden email]>
> >> 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: [hidden email]
> >> >> > For additional commands, e-mail: [hidden email]
> >> >> >
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All] What's in a "beta" release?

Gilles Sadowski
On Fri, 31 Aug 2018 10:35:32 +0200, Benedikt Ritter wrote:
> This discussion keeps popping up every few month. At the end we alway
> conclude that we don't want to publish anything that's binary
> incompatible
> under the same coordinates.

There was no such conclusion, as Gary's answer shows: "alpha"
and/or "beta" are, in principle, more free.
But at the same time, in practice, it is always frowned upon
when BC is broken.

> So way are we discussing this again? Appending
> "beta" to a release version will not stop people from using it.

Sure; it was exactly my point in asking: Do we care about
potential JAR hell in a "beta" release?

> So why not
> simply call it 1.0 and be done with it?

There isn't a unique answer. If you look back in the ML archive,
you'll see that I favoured your above opinion for e.g. [Text]
because it was actively developed, so that no big changes were
expected between the "beta" release and the "ordinary" one.

Here, the situation is quite different, as I've briefly exposed
in the other thread ("[Math] Beta release").

So, in a nutshell, I think that here at "Commons" we must define
what we mean by a "beta" release and how to make one.
Let's list points beyond the BC (which is indeed settled: i.e.
no BC breaking without package name change).

Gilles

> Benedikt
>
> Am Fr., 31. Aug. 2018 um 01:30 Uhr schrieb sebb <[hidden email]>:
>
>> On 30 August 2018 at 15:35, Gary Gregory <[hidden email]>
>> wrote:
>> > But SNAPSHOT builds _are_ publicly available on
>> repository.apache.org.
>> Sure
>> > they come and go and you cannot rely on their permanence.
>>
>> Just about all our code is available from URLs that don't require
>> logins.
>>
>> However only formal releases should be announced to the general
>> public.
>>
>> Other links should be confined to pages intended for Commons
>> developers
>>
>> > Gary
>> >
>> > On Thu, Aug 30, 2018, 04:50 sebb <[hidden email]> 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 <[hidden email]>
>> 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 <
>> >> > [hidden email]>:
>> >> >
>> >> >> 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
>> <[hidden email]>
>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]