WildFly Lifecycle

[Sizum]

Hello!
Tell me, is there a link to the WildFly lifecycle?
Is there a RoadMap?
Which version is recommended to use?
Does WildFly have such a concept as end of support?

How can I find out which defects are relevant for a particular version? Is java 8 going to be phased out. If so, when?

Thanks in advance for your reply

[Max N]

Hello!
Tell me, is there a link to the WildFly lifecycle?
Is there a RoadMap?
Which version is recommended to use?
Does WildFly have such a concept as end of support?

Is java 8 going to be phased out. If so, when? Is it possible to see somewhere the current defects by version without waiting for the release. Is there a release migration cycle?

[Emmanuel Hugonnet]

Le 14/01/2022 à 07:33, Sizum a écrit :
> Hello!
> Tell me, is there a link to the WildFly lifecycle?
> Is there a RoadMap?

Usually we release about every quarter and we have a maintenance release around 1 month after the release.

> Which version is recommended to use?

The latest

> Does WildFly have such a concept as end of support?

There is no concept of support for WildFly.

> How can I find out which defects are relevant for a particular version?

Release notes

> 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 received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wildfly/ba790a0b-e251-418c-a274-baa6917df7c6n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/ba790a0b-e251-418c-a274-baa6917df7c6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Brian Stansberry]

I'll say a bit more beyond what Emmanuel's already said.

On Friday, January 14, 2022 at 12:42:37 PM UTC-6 ehug...@redhat.com wrote:

Le 14/01/2022 à 07:33, Sizum a écrit :
> Hello!
> 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.

If you're looking for a server based on the WildFly technology stack with a formally defined lifecycle and high quality support support I recommend Red Hat JBoss Enterprise Application Platform -- https://www.redhat.com/en/technologies/jboss-middleware/application-platform

> 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:

https://www.wildfly.org/news/2021/09/27/WildFly-Changes/

I'm @bestansberry on Twitter. I tweet when I post on wildfly.org/news and try and tweet when other posts are added.

2) If you subscribe to the wildfly-dev mailing list (https://lists.jboss.org/archives/list/wildf...@lists.jboss.org/) developers often announce when they are beginning analysis work on a new feature. That analysis is captured in a PR sent to https://github.com/wildfly/wildfly-proposals/pulls. You can follow that page or watch individual PRs there to learn more about upcoming features. But there's no time commitment involved.

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?
The latest
> Does WildFly have such a concept as end of support?
There is no concept of support for WildFly.

Other than asking questions here or in https://wildfly.zulipchat.com/#narrow/stream/196266-wildfly-user, or filing bug reports or RFEs in JIRA. But there is no kind of SLA for any of those. For questions asked here or in zulip, community members answer if they can.

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?
Release notes
> Is java 8 going to be phased out. If so, when?
Yes. Nothing is currently defined as far as i know.

I get into this in my https://www.wildfly.org/news/2021/09/27/WildFly-Changes/ post. I plan to provide an update on this in the next couple weeks, via wildfly.org/news and a thread here.

 

>
> Thanks in advance for your reply

You're welcome and thanks for asking. 

Best regards,

Brian Stansberry

WildFly Project Lead

He/Him/His

[Max N]

Thanks everyone for the replies. If there is a technical difficulty, is it better to write on the forum or in Jira? For example, switching to new authentication parameters in versions 25 and higher

суббота, 15 января 2022 г. в 04:47:23 UTC+5, brian.st...@redhat.com:

[Brian Stansberry]

If you're essentially asking for help with something, please use the forum. We use JIRA to track changes that we'll make to WildFly project git repositories or similar things like CI server config files for project testing. So if what you're asking isn't likely to result in such a change, JIRA isn't the place for it. Your questions will also get greater visibility on the forum. JIRAs tend to only be looked at by their assignee, and how quickly they'll notice a new issue or have time to look at it varies greatly.

If you suspect you may have found a security vulnerability, please don't discuss it publicly. Instead please notify Red Hat as discussed at https://access.redhat.com/security/team/contact. Red Hat helps the WildFly project coordinate CVE filing if appropriate, along with any issue embargoes if needed.

If you're not confident if something you are seeing is a bug but suspect it is, discussing on the forum before filing a JIRA is a good idea, but filing a bug JIRA is ok.

If you have an idea for an improvement, mentioning it on the forum before filing a JIRA might benefit you (e.g. you might get useful feedback or be told about existing plans that address your use case), but doing that is not required. We don't want to discourage people filing improvement suggestions.