Provided that we can still use Java 8 or similar during the release process (probably need something like the animal sniffer plugin to ensure newer APIs aren't used), it shouldn't be too bad. I'd be in support of having a 2.3.x branch for security fixes and bug fixes. I would not be in support of adding new features to 2.3.x as that would be confusing, plus who is still making new features in Java 6 anyways? Even Spring Framework migrated to Java 8 as a baseline, and they've been incredibly conservative about backwards compatibility for quite some time now.
On Sat, 8 Sep 2018 at 11:34, Gary Gregory <[email protected]> wrote: > I can help with validating an RC vote but I really more interested in Java > 8 and beyond. > > Bringing this in a 2.3.x branch and not in 2.x-release if applicable might > be quite confusing. > > Gary > > On Sat, Sep 8, 2018, 10:14 Ralph Goers <[email protected]> wrote: > > > A request to integrate https://gitlab.com/thiesw/log4j2-Java6-extras < > > https://gitlab.com/thiesw/log4j2-Java6-extras> was made in one of the > > pull requests. This project targets Log4j 2.3. According to Nexus 13% of > > the downloads last month were for 2.3. So the questions are: > > 1. Do we want to incorporate this enhancement against 2.3? > > 2. Do we want to include it against master or release-2.x? > > 3. Do we want to fork the repo into an ASF repo and take ownership as a > > separate component? > > 4. If we include it against 2.3 are there other bug fixes that should be > > applied? I believe there might have been a security issue that was fixed > in > > a later release so that would have to be incorporated. > > 5. Can we still perform a release against Java 6? I think my machine is > > still set up for it but it has been a long time since I tried. > > > > If we do not want this component I have told the author that he can’t > keep > > the package names as they are but I would hate to have him rename them if > > we would be taking it. > > > > > > Ralph > > > > > -- Matt Sicker <[email protected]>
