search

jakartaee / platform

The Jakarta EE Platform project produces the Jakarta EE platform specification, which is an umbrella specification that aggregates all other Jakarta EE specifications.
https://jakartaee.github.io/platform/
Eclipse Public License 2.0
197 stars 66 forks source link

Jakartee Platform release cadence #124

Open carlosdlr opened 4 years ago

carlosdlr commented 4 years ago

This issue is to define the Jakartee Platform cadence

Steps to define cadence:

These are the steps that I propose, feel free to make changes if you consider that is needed.

ivargrimstad commented 4 years ago

I would like to see a 6 month release cadence for Jakarta EE Platform.

kwsutter commented 4 years ago

@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.

carlosdlr commented 4 years ago

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.

carlosdlr commented 4 years ago

+1 12 months cadence

smillidge commented 4 years ago

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.

keilw commented 4 years ago

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.

smillidge commented 4 years ago

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.

ggam commented 4 years ago

Out of curiosity, how often does Spring release new significant versions?

keilw commented 4 years ago

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 ;-)

smillidge commented 4 years ago

From here https://en.wikipedia.org/wiki/Spring_Framework roughly 3 to 4 years.

urbandroid commented 4 years ago

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.

carlosdlr commented 4 years ago

A bot in the conversation interesting 😁

On Thu, 21 Nov 2019, 18:49 urbandroid, notifications@github.com 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 .