[wildfly-dev] WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases

[Steve Ebersole]

Its a high-performance connection pool written by Luis from the performance
team.

On Thu, Dec 14, 2017 at 4:12 AM Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

>
> > + Agroal inclusion
> What's that ^^^ ?
>
> Thank you.
> Rostislav
>
> ----- Original Message -----
> > 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
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/c8f8b79f/attachment.html