git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Mon, 5 Nov 2018 19:19:25 -0700, Gary Gregory wrote:
On Sun, Nov 4, 2018 at 1:00 PM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> 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
> <brunodepaulak@xxxxxxxxxxxx.invalid> wrote:
>
>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx