> On May 11, 2022, at 6:39 AM, Matteo Merli <matteo.me...@gmail.com> wrote:
>
> On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eolive...@gmail.com> wrote:
>> I am sorry, I missed this discussion.
>> But until we cut a release we are in time to change our minds, if we
>> find out that we can do better.
>
> Yes, but the precise point of having a PIP process is to have
> discussions and formalize decisions.
One of my criticisms of the current PIP process is that there is a 2 day VOTE
period. This is just too short for ASF project governance. Not everyone is
online or checking the dev list in detail in that short a period. There are
weekends, holidays, work focus (even if Pulsar is your job). Many PIPs are
minor, but some are of very large impact and should perhaps have a 7 day VOTE
and/or 7 days minimum discussion time.
This particular PIP has a large impact and I think that even if it proceeds
there are certain additional discussions and decisions that are required.
1. We should likely declare that 2.10 releases are LTS to allow stability for
users that must remain on Java 8.
2. We’ll need to provide clear guidance to developers on code changes that will
be cherry picked to 2.10 and earlier versions.
ATB,
Dave
>
>>
>>>
>>> It is not that the PR came out of the blue. Obviously every decision
>>> can be re-visited if there are additional details, though it would be
>>> better if we get the feedback at the time the proposal.
>>>
>>> To reiterate the rationale for going directly to 17:
>>>
>>> 1. Requiring Java 11 won't buy us anything new and will at the same
>>> time require changes from the part of the users.
>>> 2. 17 is a Java LTS release that will be out for 1 year from the
>>> moment in which we release Pulsar 2.11
>>> 3. It is a stable release with widely available packages for every
>>> platform and from every Java vendor.
>>> 4. We are setting up for 4 years of active support of Java 17,
>>> compared to just 1 year of Java 11
>>> 5. There are several source-level features introduced in 12+ that we
>>> can take advantage of in our codebase
>>
>> I understand your points, and I would be really excited to start using
>> Records and other features (and Valhalla, Loop and Panama as soon as
>> they are available)
>>
>> But on the other side now in the Pulsar ecosystem we have big
>> enterprises that are not keen on changing JDK so quickly.
>>
>> Up to version 2.10 Pulsar still worked well on JDK8.
>>
>> We cannot require users to switch from JDK8 to JDK17 while upgrading Pulsar.
>
> Why not? We can ask to upgrade to Java 11 but not 17?
>
>>
>> We have been running, building and testing Pulsar on JDK11 for many
>> major releases (from 2.7 onwards) (and the docker images in 2.10 are
>> with JDK11)
>> so it is time to require JDK11.
>
> Requiring Java 11 would be pointless as there are very few Java source
> level features we can take advantage of.
>
>>
>> I believe that the best plan, in the interest of our community and of
>> the enterprises who choose to switch to Pulsar,
>> is to still allow all Pulsar components to run on JDK11 (and the
>> client on JDK8) for 2.11.
>>
>> We can switch to requiring JDK17 in 2.12.
>
> I do not agree with this assessment and I think the best plan is to
> continue with the current decision of switching to Java 17.
