Thanks for cancelling Jason. The version number we're talking about is a marketing version number, it has no technical impplications (as OSGi versioning is done on packaging level).
The API is our most core bundle, if we increase the major version number of the bundle, this sends out the *marketing* message that this is a new and incompatible API. But this is not the case, the API is fully compatible...with the addition to mention for installations using Java 8. A client of the API still runs without changes. Given the java release timeline, I think it's fine to assume that mostly everyone is using at least Java 8. Therefore we prefer to go this route and not frighten our users with major version increases. Regards Carsten Jason E Bailey wrote > Premature version bump has resulted in a cancellation > > - Jason > > On Mon, Jun 4, 2018, at 11:50 AM, Jason E Bailey wrote: >> Eh, I'm a bit confused over why a jdk requirement change is not >> considered breaking, and I don't see what the problem is with iterating >> the release rather than the version. But I'm good with changing it back. >> >> I'll cancel this when I get the chance and reset the releases and the pom. >> >> - Jason >> >> On Mon, Jun 4, 2018, at 11:39 AM, Robert Munteanu wrote: >>> On Mon, 2018-06-04 at 08:48 -0400, Jason E Bailey wrote: >>>> The major version change is from a release perspective. The only >>>> change to the versioning which OSGi uses is >>>> org.apache.sling.api.resource which went from 2.11 to 2.12 >>>> >>>> Ioan brought up the issue as part of the pull request that the >>>> upgrade to jdk 8 is a significant change. If someone is running >>>> sling on a jdk 7 environment then this release will be broken for >>>> them. I looked around at other Apache projects and there seems to be >>>> a trend that upgrades to JRE support results in a major release >>>> upgrade. >>>> >>>> This would also allow support, if there was ever a need, to do a >>>> release for the jdk7 version after this release. >>> >>> This is not our current practice - we bumped versions from 5 to 6 and 7 >>> without bumping major versions so I'd suggest we keep doing that. I >>> think the bigger suprise would be that we increase the major version >>> component without an actual breaking change :-) >>> >>> Thanks, >>> >>> Robert -- Carsten Ziegeler Adobe Research Switzerland [email protected]
