Bored? Looking to kill some time? Want to chat with other SMF users? Join us in IRC chat or Discord
Started by Oldiesmann, October 02, 2014, 07:13:55 PM
Quote from: Kindred on October 04, 2014, 08:00:55 AMDid you read the changeLog?And antechinus...We will continue to provide support in the support boards... However, we will not be patching 1.1.x any further. From now on, The recommended solution to security issues in 1.1.x is to upgrade to 2.0.x....
Quote from: Antechinus on October 04, 2014, 05:15:39 PMQuote from: Kindred on October 04, 2014, 08:00:55 AMDid you read the changeLog?And antechinus...We will continue to provide support in the support boards... However, we will not be patching 1.1.x any further. From now on, The recommended solution to security issues in 1.1.x is to upgrade to 2.0.x....Ok, so let's be clear on this. The no-BS version is that in terms of security, 1.1.x is unsupported as of now. This is a change of policy over what has consistenly been claimed for years; that 1.1.x would be patched until 2.1 was stable.That means that if an exploit for 1.1.x turns up before 2.1 is stable, which is quite possible given the pace of SMF dev, the admin of any 1.1.x site will have to turn their site upside down with a major upgrade to 2.0.x. Then, when 2.1 is stable, they will have to do it all over again if they want something up to date. 2.0.x isn't all that impressive by today's standards, and IMO has little real advantage over a well-customised 1.1.x, so this is going to be annoying. It'd be much better to just be able to go straight to 2.1, and only turn the site upside down once.Do note that there are already other forum apps, some forked from SMF and some not, that are stable now, and have very good features, and very good migration tools. If I was still adminning a 1.1.x site, I would not be taking this announcement as an incentive to upgrade to 2.0.x, because frankly there are better options available. I would be looking at those options instead. OTOH, if I could be sure of having 1.1x patched until 2.1 is stable, I would probably be more inclined to wait for 2.1.Bottom line is you may be shooting yourselves in the foot with this change of policy. My 2c.
Quote from: ♦ Ninja ZX-10RR ♦ on October 04, 2014, 05:41:06 PM@antechinusI totally agree with you. I will stick to 2.0.9 until 2.1 will have the 110+ mods that I want updated, and since this is not likely to happen in at least 10 years time I think I will upgrade directly to 3, in said time, when mods etc etc... I think you got that.
Quote from: Antes on October 04, 2014, 05:57:28 PMif some admins rather to stay on 1.1.x (which you need to downgrade your php/mysql for complete compatibility) they already "be shooting themselves in the foot"... But I agree, comparing 2.1 vs 2.0 - there is a big difference and yet its worth to wait for it, rather than going another software. To me I actually asked team to kill SMF 1.1 nearly 1 year ago, but we'll see things after first two beta releases of SMF 2.1.
QuoteI wasn't going to reply to this topic but I don't have permission to split it so, admins will split this topic soon. This topic is not for discussing other softwares/new version or problems.
Quote from: vbgamer45 on October 02, 2014, 09:10:38 PMCongrats on the release! Thanks for update to SMF 1.1.x as well
Quote from: Arantor on October 04, 2014, 07:12:33 PMWrong on your last point.Any host that upgrades to PHP 5.4 or beyond - you know, for the *supported* versions of PHP (PHP 5.3 is EOL)... will have problems with SMF 1.1.Any host that upgrades to PHP 5.5 or beyond - for the 'current' stable version of PHP - will definitely have problems with SMF 1.1.The changes are sufficient that it is not feasible to patch such things.And it has been recommended for months and months to upgrade anyway.
<operation> <search position="before"><![CDATA[ $context['config_vars'][$config_var]['value'] = unserialize($context['config_vars'][$config_var]['value']);]]></search> <add><![CDATA[ $context['config_vars'][$config_var]['value'] = !empty($context['config_vars'][$config_var]['value']) ? unserialize($context['config_vars'][$config_var]['value']) : array();]]></add> </operation>