Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
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.
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.
I realized I have access to our analytics data server.
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.
I will say that @Tim argues for the complete opposite of this and that if someone is that far behind, well they better get to installing. I'm far less optimistic about folks' understanding of PHP versions and ability to upgrade. I'm also not clear that it's a compelling goal for us as a dev team to get to 5.6. The differences are mostly performance-based, and we don't care that much if you're wasting your own CPU cycles. We already moved to 7.0.
I agree with @Tim but it could be because I use shared hosting lol.
Part of me agrees with him too, but mostly it's the part of me that wouldn't have to answer all the emails and messages and discussions that would result.
Best encourage people, blog about it an put that news in the dashboard feed.
grep is your friend.
Just upgraded to the beta in 'production' (I live life on the edge.), all seems fine so far - upgrade was smooth, nginx 1.4.6, Percona MySQL 5.6 and HHVM 3.15.1.
Will have a proper dig and test later tonight.
@painejake
I spent a couple of years in Harborne, which, as you'll know, was living life on the Edgbaston.
The host I use does not offer that edge thing lol.
@ItsVizionTv I'm a have a few VPS's and do a lot of R&D at work which helps promote my inner nerd
Everything looked really solid, I'll leave it to users to break now see if they find anything! I've moved onto testing on a more 'normal' hosting setup on CentOS7 with apache 2.4, PHP 5.4 + 5.6 and MySQL 5.6.
While at EOL I appreciate some providers still offer 5.4 as default so I bet a lot of people use it with or without knowing.
I'm usually quite good at breaking code I haven't written. Will have a good dig round.
if you are pretty confident of the first 3. How about making it easier for novice users to test.
to get this out of inertia since May (approx 5 months).
e.g. create a downloadable zip with the patches and commits thus far as indicated below and increment the beta version, or release the release candidate with the backports.
some individuals would probably want to test the latest commits of 2.3beta since it has security fixes. But they may not want to cherry pick the commits, and they may not want to fart around with composer and github. So a downloadable zip with latest commits would be a step forward to getting the release on its way out the door to new testers and a wider audience since you feel pretty good about the first 3 items in the list.
maybe someone with some smarts wil be able to give you some feedback on the install of the updated zip with commits and running on Digital Ocean and GoDaddy to get things to the next step.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
Patches since the beta I have high confidence in. That's not the part I need tested further.