Make Wonder go to 11+6 #944
Conversation
|
Nice work @hugith.
As potentially the only remaining user of ERProfiling.framework, I probably need to volunteer for this. The first problem is that I don't even have Java 11 set up in development yet. Two alternatives:
What do you think? |
|
@paulhoadley As far as I'm concerned there's no big hurry, so go ahead and test at your leisure :). Before merging I'm also wondering about the consequences for the WOCommunity Jenkins builds. Jenkins probably needs to be configured with a Java 11 JDK so it can build this thing. Also; the Wonder7 job there is building from master, meaning downloads for the Ant People would silently move to Java 11. We might want to have separate stable (7.2 on java 8) and master (java 11) builds there? @maiksd is probably the right person to provide input on that topic. |
Jenkins already has 8 and 11 installed and configured, so that's just a matter of job configuration. But yes, the Wonder7 job uses the master branch, we should separate that before moving on. But I feel this warrants a proper discussion on the mailing list first? |
Awesome!
OK, should I start that discussion or should we first discuss what the proposal is? |
Here's another idea: we could start abandoning Jenkins in favour of GitHub Actions—or is the issue that we still need to support legacy Ant-based builds for the framework build products? My motivation here is just to try and reduce the number of things @maiksd needs to maintain, and Jenkins would be a nice one to ditch. Yet another idea would be to draw an even brighter line in the sand. Wonder 8.0 would be:
Jenkins could stick around for a while to build any Wonder 7 branches, and at some point fade away. Thoughts? Too harsh? |
|
@paulhoadley You probably know where I stand on the Maven only idea, I think it would be fantastic and would make life easier. I believe most of us who currently work on Wonder use maven, and Ant users shouldn't be affected since the built frameworks will work fine with Ant. Can't hurt to propose it. I'm up for GitHub Actions too if they do everything we need. The thing I like most about Jenkins is basically @maiksd :) |
|
That Jenkins is one of three that I'm maintaining. I wouldn't mind it going away, but that wouldn't actually free me from having it in my mind in general, so no big deal keeping it really. And besides Wonder, it also serves WOLips, which would need to be migrated too. And we couldn't just abandon it and then remain unable to publish minor fixes in Wonder 7 should they be needed, could we? And I think there are still a lot of devs stuck on ant. I feel half of this community has problems moving away from what used to work for them for many years, and I'm not comfortable forcing them to. |
Yeah, I did think of WOLips as soon as I hit send on that one...
I hear what you're saying. I don't have a strong view on abandoning Ant, but let me push the argument a little further. Wonder isn't the vibrant open source project it used to be. There are fewer and fewer active committers, fewer mailing list participants every year. The resource that is "people who can and do work on Wonder" is stretched thinner than it ever has been. Given that picture, how long are we obliged to support backwards compatibility (with JDKs, build systems)? Can we ever draw a line in the sand? These are rhetorical questions for thinking about, and aren't directed specifically at you, @maiksd! |
|
Moving Wonder to Java 11 would be great. After publishing the next 7.x release, we could create a new branch |
|
I'm all for moving ahead. Call |
|
I definitely support going for 17, I only picked 11 since it was the latest LTS when I did this. The API changes required for ERProfiling aren't really a problem if it's a full move to JDK 17, without the need to maintain compatibility with older JDKs. I've upgraded the pull request to try it out, and the build runs fine on my computer (fails on GitHub due to the expired cert on |
|
I'm going to close this PR since I believe the changes made in it were added by @nullterminated in #994 |
I've been running this without problems for a couple of days now, a couple of eyes on it wouldn't hurt before it's merged.
I did not upgrade the JDK version in the "release.yml" github action to keep it compatible with 7.2. Or is that perhaps not neccessary? Not sure of the mechanics of how action configuration is handled when building older versions (does the action definiton file/jdk version come from the branch being built?)