On Mon, 5 Nov 2018 19:19:25 -0700, Gary Gregory wrote:
On Sun, Nov 4, 2018 at 1:00 PM Gilles <gil...@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
> <brunodepau...@yahoo.com.br.invalid> wrote:
>
>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
