WildFly 12.0.0.Beta1
by Kabir Khan
Hi,
WildFly 12.0.0.Beta1 has been tagged. The tag can be found at https://github.com/wildfly/wildfly/tree/12.0.0.Beta1.
I am in the process of releasing it on Nexus, and it should be available shortly.
I don't know if Jason intends to upload this for general download, or if we will wait until we release Final in a few weeks. I'll let him decide :)
As for Jira housekeeping I deleted some intermediate 12 releases for WildFly 12, and renamed 12.0.0.Alpha1 (which we have been using up to now) to 12.0.0.Beta1. All unresolved issues when releasing 12.0.0.Beta1 in Jira have been moved to the next release 12.0.0.CR1. Please use 12.0.0.CR1 to resolve issues until the feature freeze.
Thanks,
Kabir
6 years, 9 months
WildFly Feature Freeze
by Kabir Khan
Hi,
Please note that the feature freeze for WildFly 12 is now effective. You can still open pull requests with new features, but they will not be merged until WildFly 12 has been tagged.
PRs containing bug fixes can still be opened, and we will do our best to merge those.
Please take care not to add features in any component upgrades created to fix bugs.
Thanks,
Kabir
6 years, 9 months
Automatic module names: JBoss Logger please?
by Sanne Grinovero
Hi all,
I would like to start converting some of our basic Hibernate building
blocks into proper Jigsaw modules, so to enable better exprimentation
with the more complex projects, but all our projects depend on JBoss
Logger.
Just noticed it doesn't even have an Automatic-Module-Name manifest
entry, that's kind of a huge blocker for any further progress.
Would it be possible to add this header quickly and release?
Thanks,
Sanne
6 years, 9 months
WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
by Jason Greene
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
6 years, 9 months
