Here’s a new thread to discuss. In general, as Tom said, we need a champion that is going to put in the massive effort to do one of the major items of interest (Gradle, etc). If somebody wants to step up to take on one of these tasks, I don’t think others will too strongly object.
There’s still plenty of bugs and XMPP compliance issues to work through, so my preference would be to crank out more releases like what was just done with 3.9.2. But I don’t write much code, so its up to the nerds moreso than me
I created the 3.9.3 just to keep the versioning going, not to demand that release. It can always be renamed or moved if necessary.
In order to warrant a move to 4.0.0 we need a game plan… a set of features that are major enough.
I am not even sure, if things like Maven migration or dropping Java 5/6 support requires a major version update. I like what is described in http://semver.org/ and according to this, the major version is for API changes only.
The minor version (e.g. 3.10) would indicate new features and the patch version (e.g. 3.9.3) would be for bug fixes only.
I know it wasn’t done like this in the past, but it would make sense. If we would do it right, the next planned release would be 3.10 and 3.9.3 would only be for critical bug fixes, which prevents people from using 3.9.2 properly.
Personally I’d like to see a Maven migration and a Java 6 drop asap. I don’t really care if we call it 4.0 or 3.10.
But releasing 4.0.0 at some time in the future and say “we moved to Maven, fixed 10 (minor) bugs and added 5 new features” doesn’t make much sense.
Dropping Java 6 in 3.10 could mean we can change some API, which would then eventually warrant a 4.0.
E.g. Guus said in http://community.igniterealtime.org/thread/50809 we could replace the XML parsing (while he also wants to drop Java 6 for 4.0 only, so it’s kind of against what I just said).
For a 4.0 release we could also think about some more API changes. There are probably many things which could be refactored, rewritten and cleaned up.
Let’s discuss the next steps instead of talking about version numbering. If our changes legitimate a 4.0 then we could rename the version afterwards.
I go for a drop of java 5 and 6 in 3.10. It’s not a big deal but increases the performance and code qualitity by using some new java features.
In parallel we could try to migrate to another build system. I’m not sure but I think we’ve to change the packaging and then we should talk again about the upcoming version number.
If there are critical bugs in 3.9.2 one could release a 3.9.3 version (3.9.2 with selected patches).
The next version shold be 4.0 with added Java 8 and dropped Java 5+6 support. One can discuss whether dropping support for Java 6 is an incompatible API change or not. But as administrators may need to update Java I’d increase the major version number.
Moving to Gradle/Maven, Bootstrap, JSR330, etc. can be done within 4.x. As sooner as we are on 4.0 these tasks can be started.
So you would suggest to create a branch 3.9 and rename the master to 4.0. The main goal of version 4.0 is to remove Java 5 and 6 and to assemble the distribution packages with Java7. All other features like DI, Buildsystem, etc. is for Minor-Versions of 4.x?
Sounds like a plan. I like small steps / small releases. But we should reduce the amount of bugs with testing. Bugs force us to provide bugfix releases instead of developing new features.
I’m still in hope that we follow the principles of the test pyramid of Martin Fowler after the move to a newer build system.
Openfire is already bundled with Java 7. Afaik, dropping Java 5 / 6 support only means, we can start using Java 7 APIs and language features.
The more I think about it, it’s probably better to drop the Java 5/6 support in 3.10 and maybe introduce a new buildsystem. Then think about what we can do now with Java 7, and discuss things like DI, StaX, Testing for 4.0 as those things probably require some major restructuring and API changes.
Openfire has no real public API. There are plugins and this API is quite stable. But as soon as updates require work on the server one should change the major version number.
We should also drop support for Oracle 8-10, MySql 4, … to make development and testing more easy.
Beyond the various implemention details we are discussing (build system, JRE support, API enhancements), another consideration for a major release like 4.x ought to include modernizing our support for the existing XMPP standards. Some of the XEPs we support (or claim to support) have been updated since the time the implementation was originally done (like XEP-0124 BOSH and XEP-0060 PubSub), and others like XEP-0198 (Reliable Delivery) ought to be added.
Does it make sense to start a candidate list of specifications for inclusion or modernization? We already have some community feedback requesting some of these. Might be good to solicit input along those lines, especially from some of the XMPP client projects like Adium/Pidgin, Matrix and Strophe.
Here are some more thoughts from a “coding point of view”, which came to my mind while coding and debugging some stuff:
There are currently only very few tests. This situation should be changed, though I have no real idea how, because for many things it’s probably difficult to write tests.
The package structure is very flat. It’d be better to have a better separation between responsibilities / layers. E.g. there’s usually a XMPP layer, a data access layer, a Web UI, …
The package structure is also a little bit confusing (e.g. org.jivesoftware.admin vs org.jivesoftware.openfire.admin, SASLAuthentication is not in the auth package, etc. …).
Rename package org.jivesoftware to org.igniterealtime?
Deprecated and unused classes and methods should be removed.
Use JPA/Hibernate with tests against an in-memory database?
Rework some database tables? Some thoughts:
ofVCard should probably be merged with ofUser, so that ofUser has all the possible vCard values then (it doesn’t make sense to have name and email redundant in both tables)?
ofRoster does not store presence stanza. Maybe we should even store presence subscriptions in a separate table?
ofPrivacyList stores plain XML. Generally I am not a big fan of storing complex data as XML string and it might get “dirty” if we want to add support for XEP-191 (Blocking Command).
It’s very inconvenient and error prone to construct your XML elements manually (either with StringBuilder or dom4j, over and over again). This is something I have especially seen in the MUC code (e.g. IQAdminHandler). I was thinking about hiding that behind an abstraction, in order to not dealing with dom4j/Strings directly.
There’s a really huge amount of dependencies. Do we really need all of them?
Some classes should probably be moved, e.g. the MINAStatCollector class is only used by the StatCollector plugin.
Exception classes, which seem to represent stanza errors, are in the muc and pubsub package (e.g. NotAcceptableException) and should probably be in a more generic package.
Get rid of legacy/deprecated/obsolete XMPP extensions (like XEP-0090 and XEP-0091: Legacy Delayed Delivery)?
Some of these issues might be wishful thinking, since they would mean major changes (especially API), but a major release like 4.0 might be an opportunity for some of those.