6 ms·

They moved to a schedule instead of waiting for features to be finished. Basically we get a new major version release on a schedule. Everything that is finishe

by doikor 2mo ago

They moved to a schedule instead of waiting for features to be finished. Basically we get a new major version release on a schedule. Everything that is finished gets packaged in and everything else pushed to the next release. The issue before was that they marked beforehand "version X will contain feature Y" and then feature Y got delayed by 3 years which means everything else in version X also got delayed by 3 years even though they were done 6 months ago.

this_user 2mo ago
It's too many releases now. At some points, the numbers just become noise. I think most people will stick to the LTS releases, but even those come out every two years.
- OtomotO 2mo ago
  Unless you're forced at gunpoint, how can there be too many releases? Rust releases every 6 weeks, since 2016... If you don't want to update, just don't? If you feel (!) pressured, you should work on that.
  - robertjpayne 2mo ago
    Rust releases are just compiler toolchain, maybe some new syntax features. Java includes the JVM which is subject to way more security issues and needs much more frequent updating.
    - wtetzner 2mo ago
      But can't you continue to run older bytecode versions on newer JVMs? I think you can also specify the source version separately.
      - samus 2mo ago
        Yes, you can. There is no need to recompile, unless you're interested in new language features. Maintaining binary compatibility is a principal goal of the platform which continues to constrain design decisions for all future changes.
        doikor 2mo ago
        There are some actual removal of feature too (breaking backwards compatibility on purpose). But those come with deprecation warnings for years before the actual feature is removed. And even then quite often it is still possible to enable with some feature flag for a version or two.
    - OtomotO 2mo ago
      > Java includes the JVM which is subject to way more security issues and needs much more frequent updating. Then releasing more often is better, because the security fixes get out of the door faster?! If previously a Java Update took 3 years, then the corresponding JVM version would be 3 years old as well. If there were patch release in between, I see no difference to now.
      - samus 2mo ago
        Patches are released continuously. The upstream versions get them immediately and they are then backported to LTS versions. Whether the patches actually become available simultaneously I cannot say without.
  - ptx 2mo ago
    With each new Java release the previous one becomes instantly unsupported (meaning that it receives no security updates), unless you pay Oracle (or another vendor). So you are forced to update if you want security updates (or run only LTS releases, or pay a vendor).
    - pgwhalen 2mo ago
      So if the matters to you, run the LTS release, right? I'm not sure I follow the concern.
- bmacho 2mo ago
  The numbers have become meaningless noise already. This release should've been called 26.1, then 27.0, 27.1, 28.0 and so on. Year.version. How Canonical does it with Ubuntu. The current numbering scheme is annoying and distracting, bears no information yet is still error prone.
  - samus 2mo ago
    I believe that's by design: applications are encouraged to upgrade often. That's usually a smooth process for standard-conforming applications. Applications that need to move slower can stick to LTS versions. LTS hopping has become a little bit more viable since the interval has been shortened to two years, i.e., four major versions.
    - bmacho 2mo ago
      > I believe that's by design: applications are encouraged to upgrade often. I'm not sure what's your thought process here. I'm not saying they should have a release every 2 years instead of every half a year, but that their numbering scheme is bad. It makes upgrading harder. If they'd just put the date in the version field, people would know how old the software is (this applies to every software btw not just Java and Ubuntu). Their current versioning system doesn't help anyone in any imaginale circumstance.
      - re-thc 2mo ago
        > If they'd just put the date in the version field, people would know how old the software is Does it tell you anything? If this "software" just bumps the date and never provides anything meaningful it is useful to you? It's about the substance.
      - samus 2mo ago
        The official guidance is very simple and straightforward: upgrade regularly and keep eyes open for the few actual things that could cause trouble. If a project cannot keep up it can always stick to LTS versions. That's it.
  - 2mo ago
- ivan_gammel 2mo ago
  [dead]
- the-smug-one 2mo ago
  Why? Just upgrade. Make it so that your org can deal with it.
mountainriver 2mo ago
Do they have backwards compatibility guarantees? Otherwise what are we doing here?
- cogman10 2mo ago
  They do, some of the best of any language. That said backwards compatibility problems still hit as some libraries enjoy using internal APIs. It's not an every time thing and it's been easier and easier with updates.
- collabs 2mo ago
  I work with dotnet but my understanding is that some applications/ teams are still on java 8 with spring boot or whatever so it isn't like they aren't modernizing but they are choosing to do so at their own time which is fine I think

by doikor 2mo ago

this_user 2mo ago

It's too many releases now. At some points, the numbers just become noise. I think most people will stick to the LTS releases, but even those come out every two years.

OtomotO 2mo ago
Unless you're forced at gunpoint, how can there be too many releases? Rust releases every 6 weeks, since 2016... If you don't want to update, just don't? If you feel (!) pressured, you should work on that.
- robertjpayne 2mo ago
  Rust releases are just compiler toolchain, maybe some new syntax features. Java includes the JVM which is subject to way more security issues and needs much more frequent updating.
  - wtetzner 2mo ago
    But can't you continue to run older bytecode versions on newer JVMs? I think you can also specify the source version separately.
    - samus 2mo ago
      Yes, you can. There is no need to recompile, unless you're interested in new language features. Maintaining binary compatibility is a principal goal of the platform which continues to constrain design decisions for all future changes.
      - doikor 2mo ago
        There are some actual removal of feature too (breaking backwards compatibility on purpose). But those come with deprecation warnings for years before the actual feature is removed. And even then quite often it is still possible to enable with some feature flag for a version or two.
  - OtomotO 2mo ago
    > Java includes the JVM which is subject to way more security issues and needs much more frequent updating. Then releasing more often is better, because the security fixes get out of the door faster?! If previously a Java Update took 3 years, then the corresponding JVM version would be 3 years old as well. If there were patch release in between, I see no difference to now.
    - samus 2mo ago
      Patches are released continuously. The upstream versions get them immediately and they are then backported to LTS versions. Whether the patches actually become available simultaneously I cannot say without.
- ptx 2mo ago
  With each new Java release the previous one becomes instantly unsupported (meaning that it receives no security updates), unless you pay Oracle (or another vendor). So you are forced to update if you want security updates (or run only LTS releases, or pay a vendor).
  - pgwhalen 2mo ago
    So if the matters to you, run the LTS release, right? I'm not sure I follow the concern.
bmacho 2mo ago
The numbers have become meaningless noise already. This release should've been called 26.1, then 27.0, 27.1, 28.0 and so on. Year.version. How Canonical does it with Ubuntu. The current numbering scheme is annoying and distracting, bears no information yet is still error prone.
- samus 2mo ago
  I believe that's by design: applications are encouraged to upgrade often. That's usually a smooth process for standard-conforming applications. Applications that need to move slower can stick to LTS versions. LTS hopping has become a little bit more viable since the interval has been shortened to two years, i.e., four major versions.
  - bmacho 2mo ago
    > I believe that's by design: applications are encouraged to upgrade often. I'm not sure what's your thought process here. I'm not saying they should have a release every 2 years instead of every half a year, but that their numbering scheme is bad. It makes upgrading harder. If they'd just put the date in the version field, people would know how old the software is (this applies to every software btw not just Java and Ubuntu). Their current versioning system doesn't help anyone in any imaginale circumstance.
    - re-thc 2mo ago
      > If they'd just put the date in the version field, people would know how old the software is Does it tell you anything? If this "software" just bumps the date and never provides anything meaningful it is useful to you? It's about the substance.
    - samus 2mo ago
      The official guidance is very simple and straightforward: upgrade regularly and keep eyes open for the few actual things that could cause trouble. If a project cannot keep up it can always stick to LTS versions. That's it.
- 2mo ago
ivan_gammel 2mo ago
[dead]
the-smug-one 2mo ago
Why? Just upgrade. Make it so that your org can deal with it.

mountainriver 2mo ago

Do they have backwards compatibility guarantees? Otherwise what are we doing here?

cogman10 2mo ago
They do, some of the best of any language. That said backwards compatibility problems still hit as some libraries enjoy using internal APIs. It's not an every time thing and it's been easier and easier with updates.
collabs 2mo ago
I work with dotnet but my understanding is that some applications/ teams are still on java 8 with spring boot or whatever so it isn't like they aren't modernizing but they are choosing to do so at their own time which is fine I think