WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

jtgreene
Administrator

Hello Everyone,

Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
 
Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

Jaikiran Pai-2
Hi Jason,

Looks good in terms of quicker releases.

A related question, given this proposal, would it mean there will never
be Alpha, Beta, CR of WildFly releases anymore? Furthermore, every
release starting WildFly 12 will now be a major release (in terms of
version numbers and even feature/changes)? What I mean is, once WildFly
12 is released, there won't be any more releases of 12.x (for example,
12.1.0 etc...)?

P.S: Unrelated - is there any issue with mail delivery to this list. I
received this mail just a few minutes back while the mail actually seems
to have been sent a couple of hours back?

-Jaikiran


On 14/12/17 8:21 AM, Jason Greene wrote:

> Hello Everyone,
>
> Release Model Changes
> ————————————————————-
> In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.
>
> The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.
>
> This has a number of advantages:
>
> A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
> B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
> C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
> D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner
>
> Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).
>
>
> [1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.
>
> [2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.
>
> [3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).
>
>
> Java EE8
> ————————
> As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.
>
> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
> ————————————————————————
> + Adopt new release model
> + Java 9 improvements
> + Servlet 4
> + JSON-B (incorporating Yasoon)
> + CDI 2
> + JSF 2.3
> + Metaspace usage improvements
> + early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
>  
> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
> ———————————————————————————-
> + New EE Security Spec
> + Adoption of provisioning
> + JPA 2.2
> + JAX-RS 2.1
> + BV 2.0
> + Agroal inclusion
>
> Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.
>
> Thanks!
>
> -Jason
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

Gunnar Morling
In reply to this post by jtgreene
Hi Jason,

+1 for the plan to do time-boxed releases with a three month cadence.

Maybe you could break down the schedule of a given release iteration a bit further, so e.g. if WF 12 is scheduled for February 28th, what are the mile stone dates for delivering PRs with new developments in WF itself, component upgrades, bugfixes etc.? Having a schedule like for instance OpenJDK has [1] would be helpful, so everyone knows what needs to be done by when.

Speaking about BV 2.0 and HV 6, we're ready to deliver this (in last week's Hibernate team meeting we agreed on sending a PR for updating WF this week). We've done a couple of 6.0.x releases (at 6.0.6 atm.), i.e. it has been honed nicely and also performance has been improved significantly [2]. So I'd hope we can included this in 12 already?

Thanks,

--Gunnar


2017-12-14 3:51 GMT+01:00 Jason Greene <[hidden email]>:

Hello Everyone,

Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)

Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

Andrig Miller
Nice write up on the performance for Hibernate Validator.

This stands out to me:  In a hot path, even the slightest instance creation might introduce some undesired overhead.

This is what I emphasized during my recommendations slides in my presentation on Tuesday.  The allocation rate is critical to good performance and scalability.

Nice job.

Andy

On Thu, Dec 14, 2017 at 6:15 AM, Gunnar Morling <[hidden email]> wrote:
Hi Jason,

+1 for the plan to do time-boxed releases with a three month cadence.

Maybe you could break down the schedule of a given release iteration a bit further, so e.g. if WF 12 is scheduled for February 28th, what are the mile stone dates for delivering PRs with new developments in WF itself, component upgrades, bugfixes etc.? Having a schedule like for instance OpenJDK has [1] would be helpful, so everyone knows what needs to be done by when.

Speaking about BV 2.0 and HV 6, we're ready to deliver this (in last week's Hibernate team meeting we agreed on sending a PR for updating WF this week). We've done a couple of 6.0.x releases (at 6.0.6 atm.), i.e. it has been honed nicely and also performance has been improved significantly [2]. So I'd hope we can included this in 12 already?

Thanks,

--Gunnar


2017-12-14 3:51 GMT+01:00 Jason Greene <[hidden email]>:

Hello Everyone,

Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)

Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

jtgreene
Administrator
In reply to this post by Jaikiran Pai-2

On Dec 13, 2017, at 11:32 PM, Jaikiran Pai <[hidden email]> wrote:

Hi Jason,

Looks good in terms of quicker releases.

A related question, given this proposal, would it mean there will never
be Alpha, Beta, CR of WildFly releases anymore?

So with the master branch becoming always stable, and with the short windows I think Alphas and Betas are largely superseded by the nightly builds (effectively there is a release every night!). However if there is a strong desire for a Beta or a CR we could cut one. The overhead is small seeing as you can just take any commit from master.

Furthermore, every
release starting WildFly 12 will now be a major release (in terms of
version numbers and even feature/changes)? What I mean is, once WildFly
12 is released, there won't be any more releases of 12.x (for example,
12.1.0 etc…)?

We would still do interim releases but only on-demand as needed, when there is a major bug (or bugs) that can’t wait for the next cycle. Additionally as part of the provisioning work we are working on, we aim to have the ability  for overlay delivery streams that are external to the official delivery. As an example, the BV/HV project might want to provide a “latest” stream that you can subscribe to that always gives you the absolute latest HV version before its formally brought into WF master. 


P.S: Unrelated - is there any issue with mail delivery to this list. I
received this mail just a few minutes back while the mail actually seems
to have been sent a couple of hours back?

Yes, lists.jboss.org is having delays. Sorry for the inconvenience. It’s being worked on and will hopefully be resolved soon.


-Jaikiran


On 14/12/17 8:21 AM, Jason Greene wrote:
Hello Everyone,

Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)

Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

Jaikiran Pai-2

On 15/12/17 4:46 AM, Jason Greene wrote:

On Dec 13, 2017, at 11:32 PM, Jaikiran Pai <[hidden email]> wrote:

Hi Jason,

Looks good in terms of quicker releases.

A related question, given this proposal, would it mean there will never
be Alpha, Beta, CR of WildFly releases anymore?

So with the master branch becoming always stable, and with the short windows I think Alphas and Betas are largely superseded by the nightly builds (effectively there is a release every night!). However if there is a strong desire for a Beta or a CR we could cut one. The overhead is small seeing as you can just take any commit from master.

My personal opinion based on what I have seen in the forums is that there's very few users who really download a nightly build to try out new things. I do know there are some who do that and do report issues, but most of the times, it's only when there's some kind of announcement about a "release", they try out the version. So I think having a CR (if not a Beta) a couple of weeks before the actual release, backed by an announcement about the CR would help get some real usage for that version.

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev