AnsweredAssumed Answered

Openfire 4.0 (Draft for discussion)

Question asked by Dave Cridland Champion on Nov 20, 2015
Latest reply on Nov 25, 2015 by RobertoJCSC

Unless you've not been following Openfire development, you'll have noticed a huge volume of new patches and activity over the past few weeks, and you'll know that the master branch on github has quite a few new features, including MAM - the new message archiving management specification, SCRAM authentication, and a simple implementation of XEP-0198's stream management protocol. There's Guus der Kinderen's new Certificate management UI in the administration console, and a bunch of code to tidy up how that operates behind the scenes, enhancing security. In addition, you're probably aware that a huge number of code clean-up patches are going through, mostly by CSH.


Most of our bugfixes have also ended up on the 3.10 branch, where Daryl Herzmann made a new bugfix release just a few days ago, and we'll be continuing those bugfix releases for a long while yet.


But it's time to start moving toward stabilizing the master branch and releasing it.


Originally we've been talking in terms of this release being 3.11.0, but given the levels of work and new capabilities, and the desire to signal that Openfire is very much moving forward, we think that 4.0.0 is a better version number. In order to do that, we're going to move to requiring two sign offs from committers other than the original author for any Pull Request to be merged as from now:


All PRs now require sign-off from two other committers.


So I'm going to propose some dates. I'd like to cut off new features - so we can stabilize what we have - in a week's time:


Feature Freeze: Friday 27th November 2015.



Then I'm going to say that we have two weeks after that to stabilize the code. Pull Requests will still be accepted as long as they're not adding new features, but over the following two weeks we'll be expecting those changes to be reduced in scope as we become more risk-averse. After those two weeks we'll create a new branch and issue a Beta release:


Beta Release: Friday 11th December 2015.


Then we allow the community to bed this in and test, allowing only bugfixes for which a workaround is not acceptable, until a final release in early January:


Final Release: Friday 8th January 2015.



Then we can breathe...


This is a draft for discussion, I can change the dates if needed, but I'd like to be quite aggressive in getting this out in a reasonably short timeframe. Once we're happy I'll repeat this post in the dev space.