I'll say a bit more beyond what Emmanuel's already said.
Le 14/01/2022 à 07:33, Sizum a écrit :
> Tell me, is there a link to the WildFly lifecycle?
WildFly has no formal lifecycle. The developers with merge rights to the WildFly code base and particularly myself as the project lead aim to communicate to the WildFly community how we expect the project will be producing releases. We're a mature project with widespread use so we aim to communicate in advance about any significant shifts we expect.
Our practice for many years now is to always move forward, so once we produce a .Final feature release we no longer produce any updates to previous feature releases.
> Is there a RoadMap?
Usually we release about every quarter and we have a maintenance release around 1 month after the release.
Yes, our practice over the last several years is to produce a feature release roughly quarterly, followed by a micro (largely bug fix) release about a month later. The roughly quarterly releases have had a new major version. We occasionally do a smaller feature release in between with a minor version number bump.
As I noted above, the project does not produce bug fix releases from major versions older than the most recently released one.
The version numbers of WildFly feature releases don't have a great deal of semantic meaning; i.e. typical feature releases have a major version bump, with some mix of features, bug fixes and possibly breaking changes, and then if we produce a minor release that use of a minor implies a smaller number of changes overall.
We do work hard to avoid breaking changes, but there are periods where that is not possible, particularly when the various specifications we implement themselves have breaking changes. We do try to monitor the overall enterprise Java ecosystem and try to get any breaking changes we need to make done over a fairly concentrated period (say a year) so that we can then have a much lower number for a while. This is only a best effort thing though; there is no commitment to that practice. We are currently in a period where we're making a lot of changes.
We would try very hard to avoid breaking changes in a minor release.
A micro release would only have breaking changes if they were necessary to correct a critical flaw, typically a security vulnerability.
If your question about roadmap is also about what features will be delivered when, we basically make little or no promises about that. There are 3 basic ways to learn about upcoming feature work:
1) Monitor https://www.wildfly.org/news/
. Developers post there about their big upcoming plans and sometimes I will post very high level statements about plans. An example is here:
I'm @bestansberry on Twitter. I tweet when I post on wildfly.org/news
and try and tweet when other posts are added.
3) You can monitor JIRA, but generally that is best for watching particular issues you are interested in, or seeing what has already been resolved for an upcoming release. For any unresolved issue, information in JIRA is not a reliable way to determine when the issue will be resolved.
> Which version is recommended to use?
> Does WildFly have such a concept as end of support?
There is no concept of support for WildFly.
For bug reports in JIRA it's best to see if your problem exists in the latest release before filing a report. If that's not possible it doesn't mean that no one will look at your report, but the harder it is for developers to reason about what your problem might be the more likely it is you'll be asked to reproduce the problem on the latest release. This is partly because it is very unlikely that a fix would be created for previous release code.
As noted above it is very unlikely that a bug fix would be delivered in any release other than the micro being produced for the most recent feature release.
> How can I find out which defects are relevant for a particular version?
> Is java 8 going to be phased out. If so, when?
Yes. Nothing is currently defined as far as i know.
> Thanks in advance for your reply
You're welcome and thanks for asking.
WildFly Project Lead