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

Thu Dec 14 11:43:31 EST 2017

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 <gunnar at hibernate.org>
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
>
> [1] http://openjdk.java.net/projects/jdk/10/
> [2] http://in.relation.to/2017/10/31/bean-validation-benchmark-revisited/
>
> 2017-12-14 3:51 GMT+01:00 Jason Greene <jason.greene at redhat.com>:
>
>>
>> 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
>

-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/23d37e4a/attachment-0001.html 