What does semantic versioning break? The versioning of Jakarta Specs is quite a mess, not so much the final versions, but Milestone or Pre-releases that are often quite diverse: https://central.sonatype.dev/artifact/jakarta.enterprise/jakarta.enterprise.cdi-api/4.0.1/versions https://central.sonatype.dev/artifact/jakarta.mvc/jakarta.mvc-api/2.1.0/versions https://central.sonatype.dev/artifact/jakarta.nosql/api-parent/1.0.0-b5/versions MVC moved from "1.1-RC1" to "2.0.0-RC2" applying semantic versioning, while "your" CDI spec among these 3 examples broke with semantic versioning a while back with versions like "4.0.0.Beta3" instead of "4.0.0-B3" or "4.0.0-BETA3". What does really break backward compatibility is the requirement to run on Java 17 or even 21 as a minimum JDK Version, but so does Spring 6 and several others. And the mentioned COBOL also has end of support, see https://www.ibm.com/docs/en/cobol-zos/6.3?topic=information-cobol-compilers-by-name-version, which in recent versions like Version 6 Release 1 also is quite short, from 2016-03-18 to 2022-09-30, meaning you could still run an older one without touching it (just like say Java EE 7 or Jakarta EE 8) probably for decades, but if you need support by the vendor, then you have to upgrade your system every 5-10 years at the very least. Werner Sorry, but the whole referenced email threads does NOT cover pruning rules at all! The whole question is about guaranteed stability over a forseeable version range. I have no problem with deprecating features. I also have no problem with pruning long time deprecated code. But I DO have a problem with intentionally (or planlessly) breaking backward compatibility from one EE version to the next *WITHOUT* any reason! For swapping the default meaning of empty beans.xml files please ask yourself: * was there really no other way to solve the problem? * was there a groundbreaking new feature which would not have been possible without this change? * was this change thus really technically necessary? * was it worth to break the world just because someone thought it might be funny? PS: failures as such can happen, no problem. But then let's solve/undo those failures and not codify them!
Am 28.01.2023 um 17:43 schrieb Scott Stark <starksm64@xxxxxxxxx>: I created an issue to update the page: I don't know that there was ever a formal vote, but the context is found in this issue and platform thread. https://github.com/eclipse-ee4j/jakartaee-platform/issues/449 I would also like to see the discussion or minutes from a meeting where this was decided. I believe that this is a thing that requires a ballot. It§s true that we had to bend the rules for Jakarta EE 9, but it's not a reason to keep bending the rules for all the future releases. It's also true that Jakarta EE 10 dropped some deprecated functionality, which used to be allowed in Java EE but the rules for Jakarta EE in https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements don't cover this option. Even if those rules are still valid, they aren't complete, and even state this explicitly in one place: XXX - This section needs to be updated with new rules for the actual removal of APIs and specifications from the Jakarta EE platform as anticipated in Jakarta EE 9, similar to what’s done for the Java SE platform.
I suggest that we update the https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements page to be up to date with the current Backwards Compatibility Requirements (Decided by whom? Jakarta EE Steering or Specification Committee? ). We can't accept that we have an official document that we don't follow, and, on the other hand, have some unwritten non-transparent agreement that some of us follow.
All the best, Director, Jakarta EE expert Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932 Wow, really. I'm speechless. Do the people who decide such things IN THE DARK (aka undocumented it seems) mean this serious? I mean, really this got nowhere made public, was it? Please point me to the articles covering this! That would imo TOTALLY ditch the whole purpose of JavaEE / JakartaEE in my eyes. If a project wants to use quickly evolving technologies, then they do usually NOT choose JavaEE. JavaEE - in my experience - was previously chosen by companies and governmental organisations whose primary goal is stability over a very long period of time. We are talking in 5 to 10 years of stability. Now when you folks ditch this, then I fear we will loose banks, governments, etc. Those 'slow moving dinosaurs' in my experience used to be the main users of JavaEE. They provide the main money, they have the most code running in JavaEE. There is a good reason why people used to say "JavaEE is these days COBOL". That's because COBOL apps are running till today. Like many JavaEE apps I see at customers. Many of them older than 10 years, but still perfectly maintainable. And for container vendors: why should I pass a TCK if the rules are totally turned around in 2 years anyway? I mean this is a joke, really :( PS: Scott, I understand you are just the messenger, so no personal offense meant.
We have switched to a semantic versioning approach, but I don't see that this was captured in that page or elsewhere. That notion of backwards compatibility was completely violated in the EE 8 to EE 9 release due to the package rename, and in general, maintaining such stringent backwards compatibility was seen as counterproductive to evolving the platform. Hi! I wanted to ask whether the following document is still valid and applies to Jakarta EE10? Or is there a newer version and where can I find it?
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev |
