Skip to content
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

Closed
mebigfatguy opened this issue Mar 18, 2022 · 5 comments
Closed

Seems odd you would drop jdk 8 support in an *.*.* release #139

mebigfatguy opened this issue Mar 18, 2022 · 5 comments
Labels
question Further information is requested
Milestone

Comments

@mebigfatguy
Copy link

too late i guess, but a major upgrade number probably was the thing to do.

@aclement
Copy link
Contributor

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.

@kriegaex
Copy link
Contributor

kriegaex commented Mar 19, 2022

@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".

@kriegaex
Copy link
Contributor

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

@kriegaex kriegaex added this to the 1.9.9 milestone Mar 21, 2022
@kriegaex kriegaex added the question Further information is requested label Mar 21, 2022
@kriegaex
Copy link
Contributor

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.

@mebigfatguy
Copy link
Author

mebigfatguy commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants