Thanks for the heads up Daryl,
New version of Jitsi Videobridge 1.3.0 plugin ready to to be released with Openfire 3.9.2
Looks good … thanks for driving this.
One comment about OF-705: the XSS vulnerabilities have actually been fixed (per the original request). The ticket remains open pending additional work to mitigate the remaining CSRF vulnerabilities.
Perhaps we can mark OF-705 as fixed (a significant improvement), and open another new ticket for 3.9.3 to track the pending CSRF work. What do you think?
Sounds good, done.
OF-125 could go off the list in favor of OF-24, OF-297 or OF-720 (one of, all three are the same in fact).
Maybe also include OF-722 or OF-633 (which also had the same cause). People had trouble with offline storage.
OF-758 (Message Carbons) was a major change (addition), too, which people asked for.
Thanks for pushing the release!
Thanks for the feedback, I have adjusted the list. OF-125 is very important to me
I took some further liberties from the draft. Congratulations all!
http://community.igniterealtime.org/blogs/ignite/2014/04/30/openfire-392-has-bee n-released
1 Like
Nice job team! Good to see Openfire continuing to move forward.
What’s the plan now after the release?
I thought 3.9.2 might be the last 3.x release and we could move on with the 4.0.0 issues, but in Jira I saw there will be a 3.9.3.
I was especially thinking about the Maven migration (OF-546) and dropping Java 5 and 6 (OF-466), but also some other changes scheduled for 4.0.0 or even consider API changes (major releases usually allow for it).
Should we move on with the 4.0.0 issues on the trunk/master and only fix (critical) bugs in the 3.9.3 branch?
I am not familiar with maintaining different branches/tags in git and merging stuff from one to the other, but on the other hand I think it would be the correct way to go.
We will likely need (at least) a 3.9.3 given the number of changes released with 3.9.2 and relative lack of testing. Also, if we are unable to generate enough lift for a 4.x (with significant API/architecture changes), we can continue with 3.10.x, 3.11.x, etc. as needed to move forward with some of the smaller enhancements, spec conformance issues, etc.
I am not opposed to moving forward with a 4.x initiative, but I’m not sure we have a clear vision statement around the effort, nor enough community dev/test resources available at the moment to do it well. I would recommend that we use a development branch for any 4.x work and stay on the trunk/master for 3.x until we have a solid game plan.
Hi CSH,
i started to play with Gradle (instead of Maven) to introduce a new buildsystem for OF 4.0. It’s not finished yet because the 1800lines Ant-Monster is hard to beat! You could find it under https://github.com/SvenBunge/Openfire/tree/GradleNewStructure2 (I tried some scenarios, long story … to long for the current discussion)
I think we should pick us some Features and start with OF4 on the master. Some suggestions:
-
Drop Java 5/6-Support: C2S and S2S build on top of the TLS-Handling of Java. Only the latest Java7 is able to handle longer DH-Parameters for example.
-
Switch to Gradle oder Maven: Gradle is more easy to migrate because it could use libraries that are not available in a repository. It’s also more flexible.
-
Other artefact-Style: We could deploy a war-file for example. Then users could deploy it on their given infrastructure instead of the bundles jetty
-
Switch to latest Jetty-version
-
Use Apache Mina 2 (or another NIO-Framework) for all of our C2S and S2S-Stuff. (But please lets migrate to a new buildsystem first
) -
Move to another GUI technology. For example Bootstrap.
-
Use Spring or another JSR330-Provider to get the componentes/classes decoupled. Then we could test it even better.
But first I would suggest to move this discussion out to a new thread instead 
I would prefer to start with a new buildsystem and I could support the move if you ask for it.
Sven