Hi all, I believe we're encountering the issue related to cherry-picking to the release branches.
Since the master is on JDK17 now it is allowed to use language features from jdk9 onwards. This is a horrible problem for those pulls that need to be cherry-picked to release branches. Now we are in a situation where Pulsar 2.10 is at early stages and we're setting it to LTS for our users. Currently we cherry-pick a LOT of commits to branch 2.10 (e.g. in the latest week we ported 43 commits). We need to figure out how to deal with this. I'll share some ideas 1) Do not use new language features until 2.10 is EOL (very long time) 2) Do allow new language features usages only for new features that we are very sure won't be cherry-picked. This is an example of a pull that needs to be converted: https://github.com/apache/pulsar/pull/15779. I disagree with this kind of "conversion" because not all the language features have an exact replacement and also the code could diverge too much and lead to conditions where other commits (maybe very important fixes) may be hardly portable. I know the main goal of this whole work is to be able to use new language features but I believe maintaining release branches is more important for the Pulsar community. What do you think? Nicolò Boschi Il giorno lun 16 mag 2022 alle ore 03:53 Jia Zhai <zhai...@apache.org> ha scritto: > Hi Dezhi, and Teng, > FYI. Here is the thread that discusses JDK 17. > > On Thu, May 12, 2022 at 8:22 AM Matteo Merli <matteo.me...@gmail.com> > wrote: > > > -- > > Matteo Merli > > <matteo.me...@gmail.com> > > > > On Wed, May 11, 2022 at 11:10 AM Dave Fisher <w...@apache.org> wrote: > > > > > > > > > > > > > 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. > > > > Sure, this is a very valid point. The initial reasoning for the 2 days > > was not to disrupt too much the introduction of smaller changes, since > > we went from no-process at all to this discussion/vote PIP process. > > > > We can (should!) definitely revisit the process, now that we have some > > experience with it. > > Typically, what would be challenging is to define what is "large > > impact" (even if this proposal certainly will fit the bill) as > > everyone could have different perspectives on it, but at least we can > > set the expectations to be different for different types of changes. > > > > The current PIP-156 stayed out for discussion/vote for 1 week (which I > > agree is not a whole lot of time), although it has been discussed > > informally in the community a few times before. > > > > What I'd also like to avoid is for us to go back on the same decisions > > once they're taken, unless there are new elements that were not > > considered before. > > > > > 1. We should likely declare that 2.10 releases are LTS to allow > > stability for users that must remain on Java 8. > > > > This sounds like a good point. > > > > > > > 2. We’ll need to provide clear guidance to developers on code changes > > that will be cherry picked to 2.10 and earlier versions. > > > > Sure, this is easy. We need to update the contributor/committer > > guidelines and the CI jobs will ensure that we don't slip anything > > inadvertently. > > >
