You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Jason E Bailey <je...@apache.org> on 2018/06/04 18:10:50 UTC
[VOTE] [CANCELLED] Release Apache Sling API version 3.0.0
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
Re: [VOTE] [CANCELLED] Release Apache Sling API version 3.0.0
Posted by Jason E Bailey <je...@apache.org>.
Thanks Carsten, I appreciate the information.
- Jason
On Tue, Jun 5, 2018, at 12:38 AM, Carsten Ziegeler wrote:
> 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
> cziegeler@apache.org
Re: [VOTE] [CANCELLED] Release Apache Sling API version 3.0.0
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org