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.

▲ bmacho 4 hours ago | parent | next [-]

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.

▲ the-smug-one 3 hours ago | parent | next [-]

I don't see the point, just increment it every release. Don't see what errors are prone either

▲ samus 3 hours ago | parent | prev | next [-]

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 3 hours ago | parent [-]

> 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 2 hours ago \| parent [-]
		> 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.

▲ doodpants 2 hours ago | parent | prev | next [-]

> Year.version

I think you mean "(Year % 100).version". Or is it "(Year - 2000).version"? Pardon me for being overly pedantic, but ever since Y2K it really bugs me when someone refers to a 2-digit number as "the year".

▲ re-thc 3 hours ago | parent | prev [-]

> The current numbering scheme is annoying and distracting, bears no information yet is still error prone.

> This release should've been called 26.1, then 27.0, 27.1, 28.0 and so on.

And how does that bear any information any differently?

▲ bmacho 2 hours ago | parent [-]

When I encounter a version number I mostly want to know either:

  - what are the major characteristics of the program
  - how old is the program

Traditional software versioning helps in the first case: they bump version after a big event (new feature, rewrite, etc). Date based versioning helps in the second case. (I prefer date based versioning over traditional or semver.) Their numbering system doesn't help anyone in any case. It's just... there. A noise.

E.g. just this article title on HN: "Java 27: What's New?" doesn't tell you whether Java 27 is old or new. "Java 26.1: What's New?" would.

	▲	re-thc 2 hours ago \| parent [-]
		> doesn't tell you whether Java 27 is old or new. "Java 26.1: What's New?" would How does 26.1 tell you that? Because you "assume" it is a date? It also still doesn't? How do you know the new 1 isn't 26.100? > Traditional software versioning helps in the first case: they bump version after a big event They pretend to. It's given most developers headaches in terms of you have to have something to bump the version so either they make something up or never do it and so fails your test either way. At the end of the day either: You care: a quick check won't hurt. It's twice a year. You don't care: what difference does it make?

▲ the-smug-one 3 hours ago | parent | prev | next [-]

Why? Just upgrade. Make it so that your org can deal with it.

▲ OtomotO 4 hours ago | parent | prev | next [-]

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.

▲

ptx 4 hours ago | parent | next [-]

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 3 hours ago \| parent [-]
		So if the matters to you, run the LTS release, right? I'm not sure I follow the concern.

▲

robertjpayne 4 hours ago | parent | prev [-]

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 3 hours ago | parent | next [-]

But can't you continue to run older bytecode versions on newer JVMs? I think you can also specify the source version separately.

	▲	samus 3 hours ago \| parent [-]
		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.

▲

OtomotO 3 hours ago | parent | prev [-]

> 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 3 hours ago \| parent [-]
		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.

▲ ivan_gammel 4 hours ago | parent | prev [-]

[dead]