According to wildfly developers: ==== http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004375.html WildFly is a community driven project and is moving fast, WildFly 10 is going to be released on October and AFAIK there is no formal support for a released version (ex.: 8.x) after the new version comes out (ex.: 9.x) there will be probably a few patches or backports to an earlier version but to stay really "supported" you must use the last available version. All WildFly versions (8.x, 9.x, 10.x) comply with the Java EE 7 specification, so if you stick to the standard then your app should run without problems in a later version. If you really need support or a formal end-of-life, then you must acquire a JBoss EAP subscription. For the moment there is only available JBoss EAP 6 wich comply with the Java EE 6 specification, but JBoss EAP 7 is on the works :-) Regards. Jorge Solórzano === That means without question wildfly80 and wildfly81 are the equivalent of EOL/unsupported. Since Wildfly90 is the current version, then conceivably wildfly82 could receive some updates. What is the plan for wildfly? becuase I do not want to see every release get it's own port. I think wildfly80 and 81 should be deprecated and removed. As soon as wildfly100 is released, then wildfly82 should be deprecated and removed. Ideally there should only be two wildfly ports: the current and the upcoming. At the very most three: current, previous and upcoming. Five is way too much IMO
(In reply to John Marino from comment #0) I added java/wildfly100 in bug 204541 a few days ago so I'll hop on CC for the discussion.
Seems reasonable, can we deprecate 8.0 and 8.1 now, and set some date of deprecation for 8.2, say 2016-07-23 (1 year from release). The reason behind many wildflies, is that I started support of jboss7, and 7.1.1 was latest release with source tarball; 7.1.3 contained critical fix, and was built only from github tag; and 7.2 was significantly different from 7.1.x. When they rebranded to wildflies, I created ports for every major branches then, just to be safe. Seems now that these numbers only marketing, and all of them show high level of compatibility. I agree that we should stick now to 9 and 10, and in future, next will be named as widfly-devel, and will substitute 10. I believe that's seems reasonable, but I think I'll post this bug to mail list for wider discussion.
The discussion did not get too far. I'm going to deprecate 8.0 and 8.1 now. Please request deprecation for 8.2 when version 10 is officially released.
Actually, I'm going to deprecate 82 as well, but set removal 6 months in the future. 10.0 is already released!
A commit references this bug: Author: marino Date: Sat Jan 9 12:30:36 UTC 2016 New revision: 405620 URL: https://svnweb.freebsd.org/changeset/ports/405620 Log: java/wildfly(80|81|82): Deprecate three EOL versions of wildfly There are currently no less than 5 versions of wildfly: 80, 81, 82, 90, and 100. According to the developers, only the current release is really supported although some security patches may get backported to the previous release as necessary. Since the current release is 10.0, only the last version of 9 could potentially receive updates. I'm setting the expiration for 80 and 81 for 1 FEB 2016. I'm setting the expiration for 82 for 15 JUL 2016 That should get 82 in the new quarterly branch and then it's gone from the trunk. That should be reasonable to upgrade to 10.0 or later by then. PR: 205490 Approved by: yerenkow (gmail) (maintainer) Changes: head/java/wildfly80/Makefile head/java/wildfly81/Makefile head/java/wildfly82/Makefile
okay, 82 is hanging around until 15 July, which is only a week earlier than you suggested (we came to same conclusion for different reasons). So when 10.x or 11.0 is released, please set the deprecation of 9.0 in motion. Thanks!