jakartaee-platform
jakartaee-platform copied to clipboard
eclipse-ee4j
Jakartee Platform release cadence
This issue is to define the Jakartee Platform cadence
Steps to define cadence:
- [x] Proposed cadence time every 12 months
- [x] Get at least 2 new different proposals apart from the previous proposed
- [ ] Vote for the proposals
- [ ] The proposal that gets more than 4 votes will be chosen
These are the steps that I propose, feel free to make changes if you consider that is needed.
I would like to see a 6 month release cadence for Jakarta EE Platform.
@carlosdlr, I'm confused by this issue. I'm not sure what you are trying to propose. Are your four steps supposed to be a single cadence proposal? And, you are asking for more similar issues with alternate proposals? Or, will we use this single issue to discuss the release cadence? Some clarification might help. Thanks.
Concerning the number of months between releases, I would propose between your and Ivar's suggestion -- 9 months. 12 months keeps us in sync with CodeOne and I'd like to break that relationship. And, 6 months would mean March and that's coming up too fast. So, something in between at 9 months which lines up around June.
Hello @kwsutter the idea behind this issue is to defined in a formal way what will be the initial cadence for the Jakartee platform in order to make it clear and transparent to the community and members, so according to our last meeting we proposed 12 months, so I added the other steps to allow to the community propose other cadence time, but if you are ok with the 12 months please comment with +1 and the cadence time for what you want to vote, as I mentioned in the steps the first proposal to get more than 4 votes will be chosen.
My gut feeling is 18 months for Major release with minors in between. However I have no evidence for that gut feeling at the moment.
I think from a user/developer point, 6 really sounds like an overkill. Projects like Wildfly seem to be a bit fast with their major release, probably feeling a similar pressure by the JDK, so jumping from Jakarta EE 17 to 18 (like the most recent Wildfly versions in June and October, 16 was only out in Feb 2019) or 19 within just a year seems quite vicious and counterproductive. Whether it's 12 or 18 months for a major release before the dot, I don't have a strong preference, but 6 or less like in the case of Wildfly or the JDK for a major version seems too fast.
So as a counter proposal for voting I will say;
18 months for major platform releases with breaking changes allowed i.e. 10.0 6 months for minor changes with non-breaking changes i.e. 10.1 but could add new non-breaking behaviour. 3 months for minor, minor platform release changes with non-breaking changes, clarifications, bug fixes i.e. 10.1.1
We follow a release train model with specs that are released swept up into the appropriate platform release.
Vendors only need to re-certify on Major (could be argued minor) releases.
4.0.0 was released in December 2013: https://mvnrepository.com/artifact/org.springframework/spring-core and it wasn't until September 2017 (nearly 4 years later) that 5.0.0 came out ;-)
From here https://en.wikipedia.org/wiki/Spring_Framework roughly 3 to 4 years.
It is reasonable for specs to not change that much since it is what they are designed for. On the other hand short release cadence doesn't have to mean frequent changes if we take JDK like approach which means all projects make their research separately and only the complete ones will be added to release.
So question is this: how long is enough to make releases small enough to ease the transition but not small that they look insignificant also we have take account the adaption and feedback time of added changes.
And this is a hard question since EE world is somewhat like jungle but my guess is that this community can create significant changes in 9-12 month easily but users will not be going to adopt that fast so shorter periods can create surprising results for users due to limited and narrow feedback.(tear between the late majority and innovators)
If communication handled sufficiently (announcements, demos, documents, feedback channels) i feel that 18 months will be optimal.
6-9 month cadence will turn users to lab rats and spec to whiteboard.
A bot in the conversation interesting 😁
On Thu, 21 Nov 2019, 18:49 urbandroid, [email protected] wrote:
It is reasonable for specs to not change that much since it is what they are designed for. On the other hand short release cadence doesn't have to mean frequent changes if we take JDK like approach which means all projects make their research separately and only the complete ones will be added to release.
So question is this: how long is enough to make releases small enough to ease the transition but not small that they look insignificant also we have take account the adaption and feedback time of added changes.
And this is a hard question since EE world is somewhat like jungle but my guess is that this community can create significant changes in 9-12 month easily but users will not be going to adopt that fast so shorter periods can create surprising results for users due to limited and narrow feedback.(tear between the late majority and innovators)
If communication handled sufficiently (announcements, demos, documents, feedback channels) i feel that 18 months will be optimal.
6-9 month cadence will turn users to lab rats and spec to whiteboard.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jakartaee-platform/issues/124?email_source=notifications&email_token=ABR2R5QABDGXZA7HTO6NLZDQU3C2NA5CNFSM4JB2LZ7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE3CWYI#issuecomment-557198177, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABR2R5V2XGWJM4VE5UGVKKLQU3C2NANCNFSM4JB2LZ7A .