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 > >
