Convopage
See the entire conversation
110 replies and sub-replies as of Sep 08 2017
Semantic versioning doesn’t work well with time-boxed releases. #javatrain
Very good news! Semantic versioning would be clearer though - a given release can always be advertised as LTS elsewhere.
You can’t be sure of a release’s version number until the last potentially-breaking change is merged, which might be quite late. #javatrain
Or is it more tool-friendly to increment it predictably, rather than possibly late in the release cycle? #javatrain
Indeed. Only changing the version when the class file format actually changes would seem a more tool-friendly approach, no?
No more than it has recently: Advance warning required for breaks in standard APIs, preferred for others. #javatrain
Will the stance on backward compatibility be expected to change?
As a general rule, yes, but there will always be room for well-justified exceptions. #javatrain
"Update releases will be strictly limited to fixes of .. bugs in newer features" So bug fixes for old features only in feature releases+LTS?
One more reason to start with 18.3! #javatrain
When is #java release 13 scheduled? Seems unlucky? #javatrain
Why not have the complete year, eg. 2018.3? Would make it clearer to understand progression imo
Version is for developers and IDE. If we published convention.. no confusion. Smaller are better.
It may be hard for tools to support features that require class file format changes that are merged late cycle, so I would say no.
Will you use FireFox versioning...I can tell people I use Java 19 in 5 years!
I love the new version system. It plays nicely with @intellijidea's 😀
We do it in Apache Kafka and haven't had issues. Releases every 4 months.
Like comparing apples and airplane hangars
Interesting — I’ll take a look.
If predictable version numbers are of particular importance, then incrementing the number (like browsers) seems preferable to year.month IMO
I wouldn't mind a version number change late in the game. Maybe tools differ. In that case integer version numbers would be preferable.
Keep turning that CD dial and the only meaningful release number is HEAD paulhammant.com/files/Trunk_Co…
Glad to see this happen! I dislike the proposed release number scheme though.
IKR? I've been advocating for desert naming scheme (eg, Gobi, Sahara, etc), but no one is going for it. @stuartmarks even built it a shed!
🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐫🐪🐪🐪
I once proposed a naming scheme based on historic explosions: Krakatoa, Santorini, K-T, etc.
It didn't go over well.
We did this at Sun. It blew up in our face.
"Wilco Tango Foxtrot" release?
Do you have an alternative to suggest?
Oooh! Oooo!!! Deserts.
How about sticking with major versions (10, 11 etc) at the start and using the "date number" as a suffix like @Payara_Fish does.
Version numbers yy.MM are fine. We will get used to it but using milliseconds would be even cooler (1519862400000L for march release)
That would be a neat way of making it *very* clear which version is an LTS release.
semantic versioning not only for the platform but for the modules would work.
Please keep the numbering for Java LTS series (Java 10, Java 11,... ) For feature releases, I suggest "Java SE 2018.1", "Java SE 2018.2" etc
Just simple incrementing numbers. 10, 11, 12, 13. Windows 95 and 98 are an example of what not to do.
Why do you consider Windows 95/98 to be bad in this regard? Because they were long-lived? Is Ubuntu’s scheme also bad? #javatrain
Year of release isn't interesting, worse it makes it seem old before it's time. IMO it is far more confusing than a simple increment.
It ties you in to this release schedule. What if you change your mind again in 10 years? Increment per feature release keeps options open.
Yes. This is why Windows 95/98 rubbish version strategy.
One could argue that tying you into the release schedule is a good thing! That helps to reinforce their time-boxed nature.
I’d say that Windows 95/98 worked out poorly because they were so long-lived and, also, not part of a larger train model, as in Ubuntu.
Following what was established by Ubuntu and is applied by many like IntelliJ seems to be a reasonable approach. So year-month seems good!
Worth noting that applications don't typically care about Linux distro versions, so that's one difference.
Key point. Java ecosystem of libraries constantly referring to version of JDK that they support. All based off single number, not two-part.
True enough — I’ll have to think further on this.
(As always, don't forget that those happy with the YY.M proposal are silent...)
And because they kept changing scheme. 95 -> 98 -> ME -> xp -> vista -> 7.
But ultimately they went back to simple incrementing numbers with 7, 8 and 10. There is a lesson for Java there!
Windows 10 or 1703 or 15063.540 ? (the current consumer version of Windows)
Sounds like discussing different things. It's not "windows 10" right now, it's windows 10.0.15063.540.
I think you forgot Windows 2000 NT? :-D
No, different train. ME and 2000 were at the same time, one for consumers, one for biz.
-> 8 -> 8.1 -> 10
Those were/are the marketing names. Under the hood there is a somewhat more logical number:
List of all Windows OS Version Numbers
Version Check is a basic operation which every developer does while building applications. Microsoft says, wrong Conditions may cause Application Compatibility issues to both developers and users, when they look at migrating the existing applications to a newer OS. The Windows version is actually composed of a bunch of different fields, all packed into an OSVERSIONINFO …
msigeek.com
Everybody knows it's the class file version that matters anyway, right? Right?!
Absolutely!
0xcafebabe, 0xcafebabf, 0xcafebac0...?
I started collecting twitter language misdiagnoses - twittertranslations.tumblr.com.
twittertranslations
twittertranslations
twittertranslations.tumblr.com
I see "making it seem old" as a good thing, gives urgency to upgrading. Java 7 doesn't "feel" all that old, but it is pretty old.
what about having 2 version numbers? Keep new scheme for every 6 months, update JDK major every 3 years, thus JDK10 in Sep 2020
I agree it's puzzling Some early thoughts of mine before we reason about it as a team: lists.jboss.org/pipermail/hibe…
Windows was bad bc it jumped back and forth btw schemes.
Introducing a new scheme and sticking with it is fine when it makes sense
I'm not @jodastephen , but in my opinion the Java spec ver. should be separate from the impl./release, easier to understand that way.
Worth noting that Ubuntu also have a name with alphabetically incrementing first letter. People often refer to ubuntu releases by this name.
But who can remember which one is which, several years later? I always have to look them up, but I never have to ask when 16.04 shipped.
Still I have to lookup if 16.04 is the LTS version or not. I'm afraid that's going to matter more for our users than it does for Ubuntu.
Yeah, I mean I honestly don't have any kind of strong opinions on this issue, merely noting that its a difference between the two schemes.
Oh please no! The use of those animal names in #Ubuntu is totally confusing. 18.3, 18.9 is really clean, simple and understandable, IMHO.
LTS not that significant for versions. Also cannot identify which are bigger releases in advance, so no release worthy of special number.
I agree with @jodastephen. Simple incrementing numbers would be better for Java release numbering. #javatrain
Just simple incrementing numbers. 10, 11, 12, 13. Windows 95 and 98 are an example of what not to do.
Java SE 9.1.3 then 9.1.9 then 9.2.3 then 9.2.9 then 9.3.3 and java SE 10
I completely agree with the proposal. This would help to add a #Java compiler to #WebAssembly as soon as they have a Garbage Collector spec.
BTW, shouldn't this be done also in #JavaEE? @delabassee
For Java EE, this is something that will need to be discussed in the foundation. See
Opening Up Java EE
-NOT SET-
blogs.oracle.com
Very good news! Semantic versioning would be clearer though - a given release can always be advertised as LTS elsewhere.
Yes, please use semantic versioning!
Agreed, semantic versioning would be best. Also, I would not mind if LTS was supported for 2 years instead or 3.
Sounds great!
It is a very ambitious plan. I hope for the best results.
Thx. I'm in favor of a more iterative release cycle. Perhaps a tweak to the versioning? Combo of long term rel ver and date: JDK 10-18.03
Would every release increase the byte code version or is this only applied if required?
Continuing to increment it in every feature release would be the easiest approach for tool maintainers, since it’s predictable. #javatrain
Yes and no. If a build tool for example encounters a new Java version, it typically fails and needs updating despite a lack of actual change
Also, LTS users might be in trouble if libraries (unnecessarily) compile to newer byte code. But I think the mainteners would be to blame.
Indeed. Only changing the version when the class file format actually changes would seem a more tool-friendly approach, no?
Will the stance on backward compatibility be expected to change?
Great proposal! Why not to move development to GitHub to simplify it even more?
github does not support mercurial
Java EE moved to Github. Also if hg is a hard requirement - Bitbucket can used instead
"Update releases will be strictly limited to fixes of .. bugs in newer features" So bug fixes for old features only in feature releases+LTS?
This is great! The $year.$month schema is confusing though. I would prefer $featurerelease.$update-LTS.
Amazing News for Java community. Every 6 months new features in Java will be released.
While I like the idea of more frequent releases, I see two problems with your proposal:
1. It takes longer than 6 months for users to expose design problems with new APIs and the current model does not allow breaking
backwards-compatibility after an API has been published. 2. Every product that has used time-based version numbers has inevitably dropped
the approach. But by then the version history is permanently polluted with high version numbers. Consider denoting the publication date
in the build number.
Agreed. I believe that 6 months is a short period.
Kudos for this big step, but why not put it on github with pull requests and automated builds via travis-ci.org?
I’m worried for the releases in 3000 and 3001, we’ll be back to 0.4, 0.9, 1.4, 1.9 ;-)
BTW, I think it's time to remove deprecated methods. If an aplication needs to use a deprecated method then it should use a Java old version
Would the multi-release JAR versioning scheme (using integers) from JEP 238 work as-is with this proposal?
No, it would need to be tweaked a bit, but that should be straightforward.
Thanks for the clarification!
Regarding educational resources and Oracle's Java certification program in particular, would you expect them to target the LTS SDKs?
Looking forward having Oracle Java web start Open sourced as OpenJDK netx is still buggy and causing problems. Yeah !!!