commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [All] What's in a "beta" release?
Date Fri, 31 Aug 2018 09:29:23 GMT
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 <sebbaz@gmail.com>:
>
>> On 30 August 2018 at 15:35, Gary Gregory <garydgregory@gmail.com> 
>> 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 <sebbaz@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 <britter@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 
>> <gilles@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


Mime
View raw message