Re-sending as this may have got lost in the recent Apache mail outage Rob
On 08/05/2014 14:17, "Rob Vesse" <[email protected]> wrote: >The vote passes with 9 total +1 votes (6 binding, 3 non-binding), no 0 >votes and no -1 votes > >As previously detailed we will go ahead with making a final Java 6 >supporting release and subsequent releases will require and be built with >Java 7 > >Thanks, > >Rob > >On 02/05/2014 09:12, "Stian Soiland-Reyes" ><[email protected]> wrote: > >>Sorry, I misunderstood your earlier email and thought you meant that the >>next *patch* version would be requiring Java 7. >> >>It is fair enough with new minor version for that, I would not champion a >>strict interpretation of semver where the major is bumped for almost any >>change! >>On 1 May 2014 16:09, "Andy Seaborne" <[email protected]> wrote: >> >>> On 01/05/14 15:53, Damian Steer wrote: >>> >>>> >>>> On 1 May 2014, at 15:51, Claude Warren <[email protected]> wrote: >>>> >>>> What are the Semantic Versioning rules? >>>>> >>>> >>>> <http://semver.org> >>>> >>>> (I assume this is the canonical source) >>>> >>>> Damian >>>> >>>> >>> which seems to be about the thing itself (the public API. which we are >>>not >>> changing). Nearest I found is: >>> >>> [[ >>> What should I do if I update my own dependencies without changing the >>> public API? >>> >>> That would be considered compatible since it does not affect the public >>> API. Software that explicitly depends on the same dependencies as your >>> package should have their own dependency specifications and the author >>>will >>> notice any conflicts. Determining whether the change is a patch level >>>or >>> minor level modification depends on whether you updated your >>>dependencies >>> in order to fix a bug or introduce new functionality. I would usually >>> expect additional code for the latter instance, in which case it's >>> obviously a minor level increment. >>> ]] >>> >>> but really the semver isn't just Java so this pushing a corner case >>>IMO. >>> >>> Andy >>>
