From the user perspective, I think it is more a problem on the engineering side than in the user side. For example...
The primary place they differ is:
- do we break compatibility bit by bit over time in an as-needed basis
In this case, you spend less time on migration and more time on innovation.
- do we break compatibility in one shot and get it over with
In this case, you spend more time on migration and less time on innovation.
The primary question here is as a user how do you want to deal with migrating and potential compatibility issues:
- bit by bit over time
- in one shot
I can change my import statements in no time, but what about my compiled dependencies? Some of them not open source?
Knowing neither path frees you from having to absorb a backwards incompatible change and the solutions would be the same, which timeline is your preferred?
I think Jakarta EE is in desperate need of innovation to be able to catch up with competition. You guys could invest in modularity for Jakarta EE 9 and eliminate the concept of micro and full profile, letting the user define his/her own profile.
