Replies: 2 comments 6 replies
-
Holding back with modifying our internal APIs until 23.x seems like a sensible suggestion, right @christianwimmer |
Beta Was this translation helpful? Give feedback.
-
That would be great. Adding supported API is fine of course, removing and/or moving existing classes to a different package would be concerning for us mid-major-release, though. |
Beta Was this translation helpful? Give feedback.
-
|
First, note that 22.3 is actually the "major" update because that is a longer-time-supported version. The goal would be to not publish svm.jar for the 22.3 release. Instead of updating a dependency on svm.jar from 22.2 to 22.3, projects should switch to the proper API and drop the dependency on svm.jar. |
Beta Was this translation helpful? Give feedback.
-
Hmm, when I said "major" I meant the semantic versioning kind of major :) I.e.
@christianwimmer This does sound like an API breaking change to me :( If that is the plan do you plan do do pre-releases of the replacement-artefact on maven central? If not, that makes it hard for downstream consumers to switch before the actual GraalVM release is out. |
Beta Was this translation helpful? Give feedback.
-
are you saying that major release as 22.0 does not signify api stability, only at the third minor it is to be expected? That changes quite a bit how we at least perceived the previous years release cadence. Basically we wouldn't be able to jump to use such releases before 22.3. I would expect that to be counter what the release scheme is intending? |
Beta Was this translation helpful? Give feedback.
-
|
There is no difference from an "API stability" point of view between any of the releases. API gets added, deprecated, and eventually removed at every release. The "xxx.3" releases are supported for at least 18 months by Oracle, while the other releases do not get any more updates after the next release is out. But that is an Oracle decision - you can decide to support any release you want for an extended amount of time. |
Beta Was this translation helpful? Give feedback.
-
|
Are you talking about product or community version here on ? We work in the community and the community roadmap says .3 is the long term support version. That's where we are planning on working and help in the community to maintain and support. Not sure why you suggest we are equally well of supporting some other version in graalvm mandrel? |
Beta Was this translation helpful? Give feedback.
-
Yes, isn't that exactly what I was saying? |
Beta Was this translation helpful? Give feedback.
-
With 22.2 running the image generator on the module path is the default. There has been some discussion about API changes (i.e. what's included in the published maven artefacts and in what package they are in) in #4616. In particular this:
Will there be any API changes in
org.graalvm.nativeimage:svmand/ororg.graalvm.sdk:graal-sdkin the 22.3.0 release? Our hope would be for such changes to get pushed to new major releases (23.x train) instead of it being part of a minor version upgrade (22.2 -> 22.3). Thoughts? Could somebody please explain your plans? Thanks very much!Beta Was this translation helpful? Give feedback.
All reactions