New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seems odd you would drop jdk 8 support in an *.*.* release #139
Comments
Hi, yeah. There are challenges with making a release, and rev'ing the early digits kick off much more elaborate process that sometimes we just don't have cycles to do. So we could either put off a release because of that process, or do it like this and at least get something out. I know it's not ideal. Major releases of 1.X in parallel with Java were easier to deal with when Java was releasing slowly, this new faster Java release schedule is harder to keep up with. |
@mebigfatguy, I feel your pain. Andy and I had long discussions several times, because after I started contributing to AspectJ I urged him to switch to a versioning scheme AspectJ used to have before, i.e. the "x" in "1.x" would reflect the corresponding Java release. The last time we used that was with AspectJ 1.9.0 and Java 9. After that, only minor-minors were incremented because of the Eclipse ceremony (reviews, IP checks) involved to get even a minor release out, not even to mention a major one. AspectJ having been basically a one-person project starring @aclement for many years, I understand that he simply could not afford to spend more time on processes than on actual coding. Now the situation is that I do most of the work which does not require Andy's deep expertise, and he occasionally helps to fix or improve something deep in the guts of AspectJ. Because I am also time-constrained and by nature even more repulsed by wasteful processes than Andy is - which is BTW why in my daytime job I have been an agile coach for 15+ years, development just being a little hobby of mine - I have been keeping up the bad practice of releasing minor-minors since I came on board before the 1.9.7 release. Concerning major releases, I was also thinking about using major version numbers reflecting the Java release, i.e. rather 18 than 1.18, 1.9.18 (or the much more probable, ugly 1.9.9). But I think minors like 1.18 would (in theory, if we were free from Eclipse ceremony) be OK, because there have not been any breaking changes in 1.x. Specifically, we did not "drop JDK 1.8 support". Yes, for compile-time weaving you do need JDK 11+ during build time, but that was forced upon AJC by the Eclipse Java Compiler which AJC is a fork of. But still, you can compile 1.8 code or - when compiling pure (non-aspect) Java code - even down to as old as 1.3. Javac does not do that for you, but ECJ and AJC do! Also LTW on 1.8 is no problem. This is all described in the Aspectj 1.9.8 release notes. Just scroll to the first bullet point of section "Other changes and bug fixes". |
@mebigfatguy: In order to make something good from your inquiry, I added an AspectJ Java version compatibility overview page to our documentation, also linking to it from the main GitHub read-me. I hope you like it. |
I just noticed that we even have had issue #72 for this topic. I created it last year. So you see that we are aware of this being a suboptimal situation. |
that's good.
water under the bridge, anyway.
…On Sat, Mar 19, 2022 at 2:28 AM Alexander Kriegisch < ***@***.***> wrote:
@mebigfatguy <https://github.com/mebigfatguy>: In order to make something
good from your inquiry, I added an AspectJ Java version compatibility
<https://github.com/eclipse/org.aspectj/blob/master/docs/dist/doc/JavaVersionCompatibility.md>
overview page to our documentation, also linking to it from the main GitHub
read-me. I hope you like it.
—
Reply to this email directly, view it on GitHub
<#139 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJRMMVNAA6QUFMIQ47YLLVAVXZTANCNFSM5RCW4ZAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: <eclipse/org
.***@***.***>
|
too late i guess, but a major upgrade number probably was the thing to do.
The text was updated successfully, but these errors were encountered: