I also don’t think we need a beta phase. There would probably be only a minority of people who would test a beta release (or only the changes).
If there’s some blocker bug, there’s the possibility to release 3.9.3 
Announcing a target release date is a good idea. Or at least an “end of coding” date, so that everybody who plans to fix some major bug or implement a feature can prepare.
May 1st sounds ok, but maybe a little later is better (it’s only 9 days until 1st May).
What’s up with the automatic Bamboo build. It takes so long to build nightlies. Can’t it build a build (Windows one with Install4J) after every source change like Spark project does? This way we won’t need beta. I can’t test latest Tom’s changes by building the project myself in Netbeans as i don’t get windows binaries and i can’t stop the server properly.
I am unsure what you are stating. The nightlys build one time per day, it has been that way for quite some time now.
So, it is once per 24 hours? As there are many more commits per day recently than it was before, every build will have a few different changes, which in theory can affect each one. It would be nice, if possible, to have once per commit build like with Spark, to test particular change and to test it faster. When i see a commit, i want to be able to download, install and test it right away, not to make a reminder to do this tomorrow or after tomorrow…
wroot, with Spark, there is now a clear indication of build numbers within the GUI. For openfire, this does not exist yet. I am not against building after every commit, but we need to bubble up more information to the admin console to make it useful…
Are you not able to build from eclipse or you need the install4j output each time?
It was useful for me with Spark even without build or version numbers, because i knew myself which build i’m installing and what i’m looking for in it.
Installer is just easier to use than building it with Eclipse/etc. You can simply copy it and install on numerous test machines. This time though the issue is that i can’t (or i don’t know how) produce installer myself in Netbeans (Eclipse whatever) and i don’t get openfire.exe launcher, only the bat file. I wanted to test how Openfire flushes MUC history on proper shutdown via launcher.
Maybe i can just drop the current openfire.exe into target’s bin folder
Hey Daryl,
yes, please release a bugfix version of openfire soon. The guys from XMPP group will switch to required TLS in S2S (and C2S) and openfire don’t encrypt connections to ejabberd (OF-745) without a new release. Scheduled for 19. Mai!
Hi BigD,
I think the concensus is to proceed with a release on 1 May.
daryl
All,
Are we all set for a release tomorow? Is anybody still hoping to push a patch before then? If so, please let me know! Ignite’s openfire is currently running the latest code.
daryl
I am ok with it.
Draft blog post message. Links will be active
The Igniterealtime Community is pleased to announce the release of Openfire version 3.9.2! This release contains a large number of fixes aimed at increasing stability and standards compliance. A full changelog can be found here[TODO:link]. Some of the notable changes include:
[OF-103] - [MUC] Allow nicknames to be used more than once in the same room
[OF-114] - Clearing cache can lock up MUC
[OF-455] - Some unicode pattern in status message can break the session connection
[OF-669] - Visually failed first login to Admin Console
[OF-714] - Add ability to encrypt properties so they are encrypted in the db and do not appear in the admin console.
[OF-745] - Use TLS-dialback even if that mechanism is not advertised
[OF-757] - Allow s2s message of subdomain of XMPP domain when no components are found
[OF-569] - Add deluser adhoc command
[OF-764] - Group chat history (MUC) should match configuration after server restart
[OF-771] - MUC service should flush recent history before shutting down
[OF-125] - Restrict discovery of rooms based on users membership
[OF-297] - fix: mutual roster deletion problem
[OF-770] - CVE-2014-2741 Uncontrolled Resource Consumption with XMPP-Layer Compression
[OF-722] - Openfire should save XEP-0184 delivery receipts as offline message
[OF-758] - Add support for XEP-0280 “Message Carbons”
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
This is the first release of Openfire after our migration of code development to Github. We’d encourage interested developers to fork Openfire and provide pull requests! Please note that we are not syncing the github repository to the previous openfire subversion repository hosted on igniterealtime.
As always, we welcome your feedback, suggestions, tips, hints, questions and other contributions in the Igniterealtime Community Forums. Please do not respond to this blog post with questions.
Here are MD5sums for the downloads available. [TODO]
OF-764 is missing
Wroot, I only included the top highlight fixes. The release notes will have them all, including this one. Are you saying this one should be included in the notable fixes?
I think OF-764 is more notable than OF-771
Having messages not saved for compliance is a major issue. Anyway, I’ll add yours as well. It does not matter to me.
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