[wildfly-dev] WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
Rostislav Svoboda
rsvoboda at redhat.com
Thu Dec 14 04:59:52 EST 2017
> + 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
More information about the wildfly-dev
mailing list