HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Vanilla 2.3 beta
REQUIRES PHP 5.4 but supports PHP 7.0! We strongly recommend upgrading PHP to 5.6 or 7.0 as soon as possible.
This is a BETA for testing. We recommend AGAINST its use in production. Please use it on localhost and staging areas to test Vanilla functionality. Do full backups of your config and database as usual before installing, and run /utility/update afterward.
If you need assistance troubleshooting this install, please START A NEW DISCUSSION. If you find a reproducible flaw, please FILE AN ISSUE with steps to recreate and "expected" vs "actual" results.
3
Comments
Hundreds of changes were made between Vanilla 2.2. and 2.3. Here is a highlight reel:
When will this update be out of beta?
@MohammadHI
There's no way to tell, and it's not really productive to ask.
Sorry.
No problem.
The nature of Beta testing means it is effectively open-ended.
Devs can give a 'ballpark' date for release, but then someone finds an unexpected glitch and that sets everything back.
Hopefully not out of beta prematurely as I encountered incompatibility with few of my plugins (saving arrays into config is no longer allowed, by design, I learned). I will change my plugins, but everything takes time as this is a side effort for me.
@Linc curious about this:
On 2.2 I'm running into a problem using BBCode via the Advanced Editor and the Quotes plugin together. Quotes seems fine with other formats, but my forum is used to BBCode and I was hoping to keep it, at least through a transition (new to Vanilla).
I'm wondering if those fixes addresses that issue.
2.3 seems close, so I won't sweat it if so (nor install NBBC or spoilers since they're core now, yay).
Do you plan to release an other beta to test out?
I know there once has been a release where you've stated that (at least) a given list of issues has to be fixed before that version could be released. Is there anything like that for 2.3?
Any milestones or labels for issues on GitHub that are required to be solved before a stable 2.3 can be released?
I feel like we need a release committee to shepherd them the last mile. It's really that I don't have the bandwidth internally to do final QA and then be on-call if there is an emergency patch needed. To my knowledge, 2.3 is ready to go, but I don't have a wide test base to confirm that.
I have enough roadmap knowledge to land features in the correct order and pick when it's time to fork for release, but the final coordination seems to be beyond me.
To be perfectly clear, I'm not suggesting I throw this on a group and tell them they're on their own. I can absolutely provide plenty of guidance and suggestions about how to finish this up. I just could use a hand, really. I have too many things pulling on me to be directly responsible for the open source release and expect it to go out on time.
Another thing: I haven't really seen any feedback on how this beta is going for everyone. I don't use it because I'm always on the bleeding edge on my sites. I think this is fine, but the dearth of sign-offs from community members gives me pause.
I am really, really bad at QA. It's absolutely my weak spot.
This is what we need to support:
To my knowledge, we are good on the first 3. The thing that drives me crazy with worry is that I drop this release and find out it breaks on Digital Ocean or GoDaddy or something.
although not as lenient but you might consider...
require php 5.6 - you would actually help clients since 5.4 and 5.5 are unsupported. http://php.net/supported-versions.php
and require rewrite urls and put the info in a clear read me about changing .htacccess and include an nginx config or at least a sample for rewriting in the download.
security in tagging needs to be backported to 2.3 if not already.
it would be nice to have other "bug" backports if 2.3 stable will be released and the newest versions of core plugins possible that work with 2.3.
would rather have a 2.3b2 which has more commits or backports.
strict mode with sql probably needs more scrutiny pre-release.
since there are so many commits that have been made since the last fork.
why not shoot for a new fork 2.4 from bleeding edge and skip 2.3
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
PS:
I will start testing 2.3.
@ItsVizionTv That gif is kinda my motto.
This is well-trod ground. https://wordpress.org/about/stats/
2.4+ will require RewriteUrls to be enabled. 2.3 is its swansong.
Our real goal is that Vanilla "just works" in a standard nginx configuration because we've started using standard server variables for everything.
Several things were added: https://github.com/vanilla/vanilla/commits/release/2.3
Now would be a particularly unfortunate moment to fork for 2.4 as the new dashboard is due for a few dozen more fixes first. Releasing 2.3 is still our best option by far.
@linc wrote: Several things were added: https://github.com/vanilla/vanilla/commits/release/2.3
Can you please validate that Make stash() use clone of sql class (#4499) is also added (I didn't see it on the above list)
Pull requests were made against the master branch. I guess you would have to make an extra PR against 2.3 so that it would be included.
Yes, please open a separate PR to pull things into the release branch AFTER they are accepted to master if you want a backport for a non-critical fix.
You can usually do this by:
master.If the commits will not apply cleanly (at the cherry-pick step), it may require redoing the patch anew on the new branch you made. This especially happens when master has sufficiently diverged from the release branch. It's also why relying on me to automatically do this is not a good strategy. De-conflicting someone else's code is only something I'm gonna do if it's a security patch or otherwise critical that it make the release. :bleep_bloop:
I realized I have access to our analytics data server. :chuffed:
PHP versions of sites that have checked in during September:
21% of Vanilla users cannot currently even upgrade to 2.2. Moving to 5.5 would double that. Moving to 5.6 would triple it, exiling nearly 2/3 of our (reported) install base to require a PHP upgrade for their forum software.
That's completely bananas.
Even arguing that it would compel some of them to upgrade, the tail of users we are already leaving behind (note we NEVER supported lower than 5.2) belies that idea.
We will inevitably move it forward again, but I have no interest in being the project out in front on this issue. It's very little trouble for us to keep the minimum version lower for now. We'll look at moving it up again for version 2.5 perhaps.