> + 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev