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. > > > > - 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 > >
