本文转载自wordpress啦
最近对WordPress旧版本的攻击不停，安全问题成为大家讨论的热点。各方的指责、谩骂也不断，当然其中也不少人讨论该如何促进WordPress的发展。我同意Jeff、David等人的看法，认为最终的责任在于网站所有者。虽然WordPress官方博客已经申明WordPress团队已经尽其所能，一些人却还一直抱怨他们是否该多做些努力。在这里我提下我个人的见解，或许会有帮助:维护旧版本。
什么是旧版本维护?
WordPress新版本都有安全补丁，同时还添加了新的功能、数据库变化以及重新设计的用户界面。很多用户对他们已有的WordPress版本的 功能已经满意，但迫于要下载安全补丁无奈只得更新其它所有的更改。根据现有的WordPress版本政策，只支持最新的版本。就如，今年夏天 WordPress 2.8.2发现了一个安全漏洞问题之后，更新后的2.8.3 版本修复了这个漏洞。而更旧的版本如 WordPress2.6.5 也容易受此漏洞攻击，但却没有这个版本对应的修复，因为已经不再支持此版本了。很多软件公司都有支持旧版本，我也建议WordPress支持旧版本，时间 也不用太久，18个月左右就行。
如何运作?
回顾下WordPress的版本发行的历史。WordPress 2.2.x 和2.6.x本该受支持。 假设一个网站在2007年六月份用WordPress 2.2 创建的，根据我的提议，在之后的18个月里，站长只需应用安全补丁(2.2.x)，而无需在2007.9月更新到2.3的版本，2008.3月更新到 2.5版本，或者2008.7月的2.6版本。2008.12月份发布WordPress 2.7的时候，2.2.x版本就可以完全放弃。而后2.6.x 成为受支持的版本: 站长只要将其更新到2.6.5版本。
根据我的提议，任何人用WordPress建站时都可以有两个选择，可以选择安装最新的版本(例如，2.8.4)或旧的受支持版本 (例如，2.6.x)。最新的版本包含了所有最新的功能，但是每隔三四个月就需要升级。旧的受保护版本不包含所有的新功能，但是在被放弃支持之前，只需要 安装安全补丁就可以：除非新的版本(例如，3.1) 发布，要不然都不需要升级到下一个受保护的版本(例如，3.0.x) 。
反对意见
大多数人应该都还记得WordPress过去是有支持2.0.x版本的。WordPress团队苦心支持了该版本将近四年，最后在七月份的时候宣告放弃。关于这个问题我曾经与WordPress的团队谈论过，我收到如下的反对意见:
1.维护工作太多
我没有办法否认这一点: 毫无疑问，比起不支持任何旧版本来说，要维护一个旧版本肯定有更多的工作要做。但是这个工作量是确定的，想想要是从一个大攻击中的负面影响恢复过来需要付 出的努力是不是更多呢？如果对WordPress旧版本的支持能使大多数的用户网站都处于一个安全的环境中，WordPress团队就可以少花多少时间应 付“WordPress不安全” 这样的言论了，也有更多的时间来开发WordPress软件。
2. 没有这种需求
当然我相信没有必要去维护2.0.x 版本。与现在的版本相比，那时候WordPress的功能也非常有限。随着网络的不断快速发展，我也不觉得有必要去维护三四年前的东西。但是，现在的 WordPress 已经日趋成熟，对于很多站长来说，当前的版本使用18个月，其功能还是足够用了。事实上，WordPress 2.6就已经是一个非常好的产品: 很多用户则需要一个安全的WordPress 2.6.x就可以了，不希望这么快就更新为一个全新的用户界面。
随着WordPress的不断发展，很多用户不再像早期用户那么通晓技术，也并不急于每隔几个月就升级新的功能。他们只需要网站能够运行，并且也害 怕更新会造成自定义的主题或插件损坏。虽然说继续维护旧的版本不会让他们从此完全脱离这个苦海，他们仍需要更新，但是却会大大减轻维护一个 WordPress网站的负担。
我在WordPress上给顾客创建网站。如果WordPress团队能够采纳我的提议，我将会在最新的版本上创建一些新的网站。然后几个月更新一 次直到成为一个受支持的版本。从此，我就可以等18月后再更新版本了。我相信很多 WordPress用户都会为此高兴的: 如果WordPress 3.0.x能够开始实施这方案就太好了。
3. 太容易让用户混淆
这个担心是有必要的，但是我觉得毫无疑问这个体制得充分向用户解释清楚。这一点，我也很乐意帮助WordPress团队。下面是我的粗略设想：
- 在“下载”页面需要有两个按钮，并在下面附上描述性的文字，如:
[下载 WordPress 3.2]
新版：包含了最新的功能，但需要经常更新:
安全补丁包即日起到3.3版本发布
[下载 WordPress 3.0.x]
旧版: 安全补丁包即日起到3.5版本发布 - 在旧版用户管理界面上的升级通知需要修改成如下面这样:
- [红色警示] WordPress 3.0.3 修正了一个此版本的安全漏洞问题，立即更新。
…或者:
[蓝色警示] WordPress 3.1 添加了新的功能。了解更多详情| 立即更新
… 或者:
[红色警示] 已经不再支持此版本的WordPress，请更新到WordPress 3.4.2 to以保安全。 立即更新。
讨论
这是一次讨论，目前为止都是我在这边唠叨，不知道各位的看法如何？你是否希望能够支持旧版本？对你自己的网站？对你客户的网站？你认为有多少用户会 使用这里的老版本？用户是否会对经常性升级感到疲劳？扎居在WordPress中用户是否觉得够舒适？这个政策是否有利于消除近日WordPress的安 全问题的负面影响？
附原文：
Supported Legacy Branches For WordPress.org?
The recent attacks on older versions of WordPress have made security a hot topic in the community. There has been finger-pointing and mud-slinging from many different directions, but there has also been some good discussion about how to move the project forward. I agree with Jeff, David, and others that responsibility ultimately lies with web site owners. While the official WordPress development blog states that the WordPress team is doing everything they can, others have been wondering if more could be done. I would like to get a discussion going here at the tavern about something that I think would help: a supported legacy branch.
What’s A Legacy Branch?
Newer versions of WordPress currently come with security fixes, but also with added functionality, database changes, and redesigned interfaces. Many users are quite happy with the functionality of their existing version of WordPress, but there is currently no way for them to get only the security fixes without also getting all the other changes. According to the existing WordPress release strategy, only the current branch is supported. When a security issue was found in WordPress 2.8.2 this summer, the new version 2.8.3 was released to fix it. Older versions like WordPress 2.6.5 were also vulnerable to this issue, but no fix was released for them because they were no longer supported. Many software companies and projects do choose to support older versions, and I would like to suggest that the WordPress team supported one legacy branch for around 18 months.
How Might It Work?
Looking back through WordPress’s release history, WordPress 2.2.x and 2.6.x could have been supported legacy branches. Imagine a site built on WordPress 2.2 in June 2007. Under my suggested system, the site owner would have applied only security fixes (2.2.x) for the next eighteen months — not needing to upgrade to 2.3 in September 2007, to 2.5 in March 2008, or to 2.6 in July 2008. When WordPress 2.7 was released in December 2008, the 2.2.x legacy branch could have been deprecated and 2.6.x could have then become the supported legacy branch: the site owner would only then need to upgrade to 2.6.5.
Under my suggested system, someone building a new WordPress site would have the choice between installing the most recent branch (e.g., 2.8.4) or the legacy branch (e.g., 2.6.x). The most recent branch would have all the latest features, but it would also need to be upgraded every three or four months. The legacy branch would not have all these new features, but it would need only security fixes applied until it was deprecated: it would not need to be upgraded to the next supported legacy branch (e.g., 3.0.x) until the version after it (e.g., 3.1) was released.
Objections
Many patrons here at the tavern no doubt remember that WordPress used to support the legacy branch 2.0.x. The branch was supported for almost four years, but the WordPress team abandoned it in back in July. I have talked with WordPress team members about this in the past, at WordCamps and over email, and I have received the following objections to such a system:
1. It’s too much work to maintain.
There is no way for me to deny it: it’s definitely more work to support a legacy branch than not to support one. But it is a known quantity of work. How much work does it take to recover from the negative press generated from large attacks? If a supported legacy branch increases the number of users who keep their WordPress installations secure, the project team could spend less time responding to the latest round of “WordPress is Insecure!” blog posts and more time working on the software.
2. There’s no demand for one.
I certainly believe that there was no demand for the 2.0.x legacy branch. WordPress then had a fairly limited set of features compared to WordPress today. Since the web is constantly evolving, I wouldn’t expect there to be a demand for software three or four years old. But WordPress today is a very mature product, and the current version will be more than adequate for many web site owners for another eighteen months. In fact, WordPress 2.6 was a very good product: many users would have preferred to stay on a secure WordPress 2.6.x instead of upgrading so quickly to a completely new interface.
As the WordPress community grows, many users are not as technically savvy or as anxious to get upgraded features every few months as in the earlier days of the project. They simply want their sites to work, and they rightly fear that an upgrade may break custom themes or plugins. A supported legacy branch would not let them completely off the hook — they would still eventually need to upgrade — but it would greatly ease the burden of maintaining a WordPress web site.
I build business web sites for clients in WordPress. If the WordPress team adopted a system like the one I am suggesting, I would build new web sites on the most recent branch. I would then upgrade my clients every few months until they reached what would become a supported legacy branch. After that, I would be able to upgrade them every eighteen months. I think many WordPress users would be thrilled to have something like this upgrade plan available to them: it would be great if it could be available starting with WordPress 3.0.x.
3. It’s too confusing for users.
This is a legitimate concern, but I have no doubt that a system like this could be adequately explained — and I’m more than willing to help the project team in designing this user experience. Here are my initials thoughts about what could be done:
- Two buttons would be needed on the “Download” page, with descriptive text beneath them something like the following:
[Download WordPress 3.2]
Contains the newest features but requires more frequent upgrades:
security patches only available until 3.3 release
[Download WordPress 3.0.x]
Legacy branch: security patches available until 3.5 release - The upgrade notifications in the administrative interface could be modified for users on a supported legacy branch. They might see something like this:
[Red] WordPress 3.0.3 fixes a security issue found in this version of WordPress. Update Now
… or this:[Yellow] WordPress 3.1 adds new features to this version of WordPress. Learn More | Update Now
… or this:[Red] This version of WordPress is no longer supported. You must update to WordPress 3.4.2 to remain secure. Update Now
Discuss
This is a tavern, and I have already monopolized the conversation for far too long. I want to hear from the other patrons: What do you think? Would you be interested in a legacy branch for your own sites? For your clients’ sites? How many users do you think would use such legacy branches? Would existing users feel less upgrade fatigue? Would more people be comfortable staying on or switching to WordPress? Could this help WordPress overcome the recent negative press about security?