Re: [jakartaee-platform-dev] Clarification on versioning and what it mea

[Mark Struberg <struberg@xxxxxxxxxx>]

Good start, but I would also like to define the rules for pruning like we used to have:

How long does some certain method/feature be marked as deprecated before we get rid of it?

This is actually what it is about. I have no problem with the removal of some long time deprecated methods and features (we used to do this in JavaEE as well, e.g. CMP - rarely but still).

Of course I do have a problem with backward-incompatible changes from one version to the other. 

I think semver is not the real problem here. Although I think it is also not really the final solution as it is too wide grained. 

What downstream users need is some well understood compatibility rules. They need time to adopt and the possibility to have a transfer phase for their code. Otherwise there is not much reason for a specification anymore if things can go willy nilly from one version to the next.

LieGrue,

strub

Am 30.01.2023 um 15:46 schrieb Manfred Riem <m_riem@xxxxxxxxxxx>:

Hi all,

 

(not sure if this is the correct list. If not, please let me know)

 

As there seems to be a bit of confusion with regards to breaking changes and versioning I would like to see a

community poll, preferably binding with the following yes or no question so it is properly documented once

and for all.

 

Should the following model be the standard for any specification in the Jakarta EE process.

 

Major version change – breaking changes OK, but not actively encouraged.

Minor version change – breaking changes not OK, only allowed to fix specification bugs.

Patch version change – breaking changes not OK

 

Thoughts?

 

Thanks!

 

Kind regards,

Manfred Riem

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev