Java 9 and beyond can be handled with version specific code in META-INF. That’s what we’re doing in Log4j for now. Based on how the new LTS schedule works, it’s better to keep updated with each new release as it comes out due to how deprecated APIs are removed now. Version specific overrides of code can be maintained for a reasonable amount of time, but I guess that really depends on how much version specific code is needed.
On Wed, Oct 30, 2019 at 15:46, Gintautas Grigelionis < g.grigelio...@gmail.com> wrote: > It will be good to be on the same page with major dependencies (and > hopefully fix that old nut listTokenValues() :-) > Please consider Java 11 for TLSv1.3 when time comes (or the next LTS > version, Java 17 when it's out -- > by then, pack200 will surely be gone...) > > Gintas > > On Wed, 30 Oct 2019 at 20:26, Jan Matèrne (jhm) <apa...@materne.de> wrote: > > > Sounds good. Similar to Ant, on branch for maintaining the version for > the > > old Java version and master for the new(er) one. > > And as suggested we shoundn't go farer than Ant itself, so Java8 is fine > > with me (no Java 13). > > > > So: +1 > > > > Jan > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Jaikiran Pai [mailto:jaiki...@apache.org] > > > Gesendet: Mittwoch, 30. Oktober 2019 15:54 > > > An: Ant Developers List > > > Betreff: Next plans for Ivy > > > > > > Now that Ivy 2.5.0 has been released, I would like to propose the > > > following ideas for the next goals for the project: > > > > > > 1. I would like to wait and watch for any bug reports for 2.5.0 and do > > > some relatively frequent bug fix releases for that version. So > > > essentially 2.5.x versions which are solely bug fixes. To accommodate > > > that, I would like to create a 2.5 branch in the Ivy project. Ivy 2.5.x > > > will continue to have minimum Java 7 as a requirement. Once we are > > > confident that the 2.5.x series is stable enough, we can stop releases > > > off that branch. > > > > > > 2. In the master branch, I would like to move Ivy to minimum Java 8 > > > version (right now we are on minimum Java 7). I would like to mention > > > that, just because we move to Java 8, the goal isn't large/medium scale > > > refactoring of existing code. This is especially important given the > > > nature of the project - the code base is complex plus we don't have > > > enough knowledge of it. It literally took me months to be able to read > > > the code and understand what I'm dealing with to be able to confidently > > > do a change that could fix some of the recent bugs (especially IVY- > > > 1580). So even though we will move to Java 8, any refactoring, just for > > > the sake of it, of existing code will be discouraged. Of course, if new > > > code is being added, Java 8 constructs/API are welcome. Also if a bug > > > fix requires Java 8 construct/API that's welcome too. We will do 2.6.x > > > releases (whenever we decide to do so) off master branch. > > > > > > Any objections to these plans? > > > > > > -Jaikiran > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > > commands, e-mail: dev-h...@ant.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > -- Matt Sicker <boa...@gmail.com>
