[All] Requirements for alpha/beta releases (Was: [VOTE] Release Apache Commons Imaging 1.0-alpha1 [...])

[Gilles <gi...@harfang.homelinux.org>]

On Mon, 5 Nov 2018 19:19:25 -0700, Gary Gregory wrote:
> On Sun, Nov 4, 2018 at 1:00 PM Gilles <gi...@harfang.homelinux.org> 
> wrote:
>
>> On Sun, 4 Nov 2018 08:06:36 -0700, Gary Gregory wrote:
>> > IMO, let's stick with 1.0-alpha1. There is no need to rush the new
>> > API and
>> > this will make the code available to all through Maven repos.
>> > Hopefully
>> > once the code is more easy to use from builds, we will get more
>> > feedback.
>>
>> What if there are requests for non BC changes?
>>
>
> I do not understand what you are getting at.

Is the name of the artefact containing "alpha" or "beta" sufficient to
allow non-BC changes?

> What I imagine:
> - release 1.0-alpha1
> - continue to improve the code, including BC-breaking changes or not.

Top-level package is "a.o.c.imaging", not "a.o.c.imaging.experimental"
(or some such); hence non-BC releases can create JAR hell.

The underlying question is what is important for allowing non-BC 
changes
without changing the top-level package name:
  * name of the artefact
  * name of the package(s)
  * release notes

I seem to recall that JAR hell must[1] be avoided, whatever the proof
that it won't be an issue in actual applications (cf. discussion for
"Commons RNG" v1.1).

> - release more alpha and/or beta versions until we are happy with the 
> API
> and are confident that we do not need BC breaking changes.
> - release 1.0.
>

I'm fine with that, and I'd favour releasing more alpha code as a
way to draw attention (especially true for some new components that
lack sufficient feedback from the current subscribers of this list).

So I want to know whether it is enough to designate a component as
"alpha" in order to be free from this requirement.

Gilles

[1] Per "Commons" (unwritten) policy.

> Gary
>
>
>> Gilles
>>
>> > Gary
>> >
>> > On Sun, Nov 4, 2018 at 12:17 AM Bruno P. Kinoshita
>> > <br...@yahoo.com.br.invalid> wrote:
>> >
>> >> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org