On Thu, 02 Jun 2016 21:35:45 +0000, Benedikt Ritter wrote:
Emmanuel Bourg <ebo...@apache.org> schrieb am Do., 2. Juni 2016 um
23:26 Uhr:
Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
> - since our components are depended upon by a lot of projects, we
need to
> take special care regarding compatibility.
+1, thanks God Apache Commons isn't like Guava or BouncyCastle.
> - we must not break BC in a release that could collide with an
earlier
> version. In other words, when we break BC, we have to change
package and
> maven coordinates.
I tend to agree but I think some exceptions should be allowed:
* If the element affected by the BC issue was released very
recently, we
should be able to roll out a new release changing it. For example if
foo
1.3 added a protected method to a class, we should be able to make
it
private in foo 1.3.1 if we release it shortly after (let's say less
than
2 months after foo 1.3).
* If the API affected is just internal stuff not intended to be used
directly, it should be possible to change it.
> - BUT since we're all doing this on our spare time, there is no
need to
> hold on old APIs just for the sake of it. For this reason, BC may
be
broken
> any time, if the steps above a followed and it has been discussed
on the
> ML. Fixes can always be backported to old releases, by people who
need
it.
Ok but this can only work if our release process is simplified,
because
backporting means publishing more releases
Great idea! Let's start a discussion about our release process right
after
we have settled an agreement about the BC topic.
[For the release process.]
I suggest people examine this document (in the "develop" branch of the
"math" repository):
doc/release/release.howto.txt
Regards,
Gilles
> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
I agree, bumping the major version isn't mandatory in this case.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
