On the substantive point here though I think we have diametrically opposed view points. Some responses below
I think you have grossly misinterpreted my assumptions, or may be, I did not articulate them appropriately.
While I don’t know if I was suggesting this I absolutely believe that a Jakarta EE implementation must be able to choose whether to implement a specific spec version or not. While the Jakarta EE community may have a view on this, and would likely wish all versions to be implemented. I think it is a stretch to far to insist that to implement one version you must implement all prior versions.
I don’t agree this is chaos, I think this is how a free market behaves. The implication of your statement would be that the Jakarta EE community decides on the service lifecycle and any implementation of the standard has to follow it and I think that is unreasonable. I take this interpretation because even if there were an LTS and non-LTS if vendor A and vendor B can choose different lifecycles for those two then you would get back to the chaos you are concerned about.
Today the Java EE standard makes no statement about how long a Java EE version should be supported for, and it is down to the Java EE implementations to decide how long their implementation will be supported for. Each community can make a decision based on what is right for their user base. For commercial products that can also be a decision based on what best allows an implementation to compete with other commercial implementations. It essentially allows the support lifecycle to be a competitive differentiator. I don’t think a lack of a statement from a standard has inhibited this and I don’t think it’ll cause it in the future either.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community