On the thread about a predictable release cycle for core, a large sub-thread opened up about the fact that everyone, including Dries, hates the way we do security vs. bug fix releases. It's confusing and unclear.
The current policy, explained
I couldn't actually find a handbook page explaining the current policy, so I made one. Here's a copy/paste of that here.
The current policy regarding release numbers is that if there's a security bug that needs to go out, two releases of the project will be created: one for just the security patches, and one for the security patches + all new bug fixes in the branch to date. This same mechanism is true of both Drupal core and contributed projects.
When we found security holes in Drupal 7.0, for example, we released Drupal 7.1 which had security fixes only, and Drupal 7.2 which included those fixes + all the bug fixes from initial release.
This approach is intended to allow site builders to upgrade immediately once a security hole is found, without the difficulty of wrangling patches, and without the terror of accidentally breaking their sites by pulling in upstream bug fixes that have not been widely tested yet.
Why people hate it
- Every time we do this, it looks like we made a mistake because the releases come out right after another.
- It's impossible to tell from looking at release numbers whether Drupal 7.5 is a security release or a bug fix release. You need to dig into the release notes to tell.
- It's really difficult to understand (even among the security team); advanced users would prefer patches.
Why the security team likes it
- The N, N+1 version numbering trick doesn't require any changes to various dependencies like Update Status/Update Manager, project packaging scripts, Drush, etc.
- The exact same process can be applied to both core and contrib, unlike slightly fancier methods "evens are stables, odds are security" that have been suggested.
- Patches are incredibly difficult for average site builders, who are the very people most likely to be harmed in an attack.
Possible approaches to solving this
- Allow "7.0.1" style releases
- Fix the packaging script to allow releases like "7.0-security" (needs to be checked with all the aforementioned dependencies)
- ...
So... FIGHT! (I kid ;))
Comments
So, I don't think this would
So, I don't think this would be too hard as long as we can verify that update module would correctly interpret the release history XML if we added e.g. 7.0-security1 releases.
We have the mechanisms in place already to make e.g. 7.0-unstable1 releases
http://drupalcode.org/project/project.git/blob/refs/heads/master:/releas...
A few spots might need to be modified, e.g. function project_release_get_version_extra_weight_map().
We'd probably want to consider whether we only allow such releases to be tagged security, or whether contrib could still tag "normal" releases as security too.
I assume we'd need to tweak some bits in the version control API too to allow you to select such a tag to make a release.
distros
On that front, what about distributions? How should they use versioning to reflect their Drupal core included version numbers and how do they express security updates then (which is basically that any of their components, core or contrib got a security update)?
Massively in favour of x.y.z style version numbering
I've started been using Drupal for about a year and half full time after working Wordpress, Rails, and Django, and the Drupal version numbering scheme has always seemed confusing to me, so it's great to see this being addressed.
I think WebChick's suggestion that we use "7.0.1" style releases makes loads of sense, and crucially, as in the form of Semantic Versioning, it's already been documented and implemented on other open source projects already, so people coming to Drupal from other communities don't have yet another Drupal-specific quirk to get used to.
Django uses something like semantic versioning - look at their docs on the release process
Wordpress also seems to do something like this - bug fixes and security patches update the third digit on releases
Likewise with Rails.
Of course, I'm not advocating blindly copying other projects just because others are doing it, but it does seem to be a fairly sensible system.
There's an interesting convo here on Stack overflow about this subject as well, with some good points.
Just my two cents.
Drupal already follows that semantic versioning doc
Except that Drupal doesn't have minor releases, so it combines major and minor into one number - ie just major.patch
Drupal dropped the minor version with Drupal 5 because changes to the minor number were effectively just as major as changes to the major number (eg 4.6.0 -> 4.7.0 was arguably a bigger change than eg 4.7.0 -> 5.0 was). Note: the Linux kernel is also now doing a similar thing and dropping a redundant minor version digit that long ago stopped having any real meaning.
And because that semantic versioning document doesn't distinguish between security fixes and bugfixes rather than avoiding backwards incompatible API changes, it doesn't really apply to this debate. The current handling of the Drupals patch digit is the same as that doc specifies - Drupal now just does two bug fix patches in quick succession instead of the one patch it used to.
--
Cheers
Anton
Data!
According to this week's usage stats, only 0.3% of sites that chose to upgrade used the security-only release (9,204 for 7.2, vs only 31 for 7.1). Perhaps more users would exercise this option if it was better understood, but it still seems like a lot of effort for a very small minority. Additionally, the target audience for sec-only releases (whom I take to be organizations with large QA budgets and low risk tolerance) are likely to be experts that could handle patches.
I think we should reevaluate if it's worth making separate security releases at all.
I'm not sure x.y.z actually helps us:
We'd have released 7.0.1 and 7.1 on the same day, which could still create the impression we made a mistake. In some ways it'd be even more confusing, because the numbers both end in .1. As far as I can tell, none of the projects linked by mrchrisadams actually make separate security releases.
Agreed with the confusion
Right, I was thinking about this exactly. If we make the versions very different, it will be still confusing, even more so. I've added a simple figure to explain the releases to http://drupal.org/drupal-7.2 (and left the existing explanation intact exactly as it was - which was clearly not enough without the visual). Then added a link to handbook page Angie wrote up for even more interested people. I'm interested in how this helps if it does :)
Small but important
It's worth noting that a great many Drupal 7 sites are still in development so the numbers adopting security-only releases for production sites may be limited. Relatedly I tend to not run update status on production sites as it causes unnecessary overhead and provides little value when the staging site is capable of telling what updates are indicated. So my D7 sites show the 7.2 version on the staging server following the release of 7.1 to production...
More importantly while the rate of adoption of the security-only release is lower that doesn't diminish it's value. It serves as insurance as well against the rare, but real, cases like Drupal 6.7/6.8 where a bugfix/hardening exercise. Certainly this is mitigated as well by vastly improved testing since those days.
Finally in my experience in organizations it's not "organizations with large QA budgets and low risk tolerance" that are the audience. It's small departments with a small but growing experience with Drupal that are part of a larger organization with established change-control processes. The larger organization dictates that emergency change control processes are limited to the narrowest possible scope but the unit/department is responsible for implementing the change (as well as often 100's of other responsibilities that aren't about Drupal). These are the departments as well where they are most likely to need to engage on the forums to get assistance and it's one thing if someone assisting on the forums can look at a tag or a tarball of code for a release like 6.21 and a different level of effort to get 6.20 and patch it to help someone. Is it possible? Certainly. Does it help make supporting the community easier and make it easy for small teams to get their toe in the door? Not as much...
--
Blog: Joshua Brauer dot com
who is the target audience?
jbrauer, is this target audience hypothetical, or are you saying you've personally worked with organizations that have asked for these special releases? If so, are the organizations in your estimation technically capable of handling patches (most likely this would be a list of git refs)?
Secondly, can anyone name examples of other software projects that make simultaneous security and bug releases? All of the examples cited so far in this thread seem to combine normal bugs and security bugs in their minor-minor releases.
I was at the meeting in D.C. when we decided to start doing this - and I still like the idea in principle. But the reality is we're creating a lot of confusion to benefit a ~0.3% minority. Is it worth it?
Making the extra release is,
Making the extra release is, imho, easier than making patches. And we need a solution that can be easily explained and works for BOTH CORE AND CONTRIB. We need a single system everywhere.
I think the -security1 type extra is the best solution if we can make it work - this is more like the way e.g. Ubuntu sets the version numbers for packages with backported security fixes:
PHP 5.2.4-2ubuntu5.12
Essentially this is what we are releasing, e.g. 7.9-security1 is 7.9 with some backported security fixes.
+security1
Yes, if we are going to make these releases -security1 is probably the right thing to do.
Ubuntu's situation is not exactly comparable - since they are repackaging software from third parties. No software project that I checked makes separate bug / security releases from the first-party distributor.
Every single one of these contains normal bug and security fixes combined into one release:
re: + Security1
Ubuntu's situation is not exactly comparable - since they are repackaging software from third parties.
What if: we consider all non core modules/themes/etc.. to be "Third Parties" (It is sort-off what they are right?) then with some sort of QA-process we repack and distribute.... Just like Ubuntu
cheers
Jos Doekbrijder
Jos Doekbrijder
S.W.I.S. GROUP
It is worth it. For
It is worth it. For organizations like mine that maintain 80-100 sites at any given time, the ability to quickly test and deploy a security release is very desirable.
x.y.z is the way to go
I agree that the current system is really confusing and x.y.z numbering looks like the way to go.
That said, I see a huge problem down the road with the current x.y method, and with separate security releases in general. At first, the "evens are stables, odds are security" idea sounds simple enough, but it's not. Suppose that I start building a D7 site today - the obvious choice would be to start with version 7.2. A month or so later, the next version is released, but one of the changes in 7.4 conflicts with my code, so I only want the security fixes. At that point, my options are:
- use 7.3, which is based on 7.1, so I will reintroduce bug that were already fixed in 7.2;
- use 7.4 and fix my own code to resolve the conflicts;
- apply security patches to 7.2 and keep patching the site for years to come.
In other words, if we really want to have security-only releases for all users, every stable minor version (like the 7.2 we have now) should get it's own security-only branch. Maybe the version numbering should be something like major.minor.security. With that pattern, the current 7.1 should have been 7.0.1 and the current 7.2 would have been 7.1.0. Following this logic, future security and non-security bugfixes would go into 7.2, while the security patches would also be applied to the 7.0 branch (resulting in 7.0.2) and the 7.1 branch (7.1.1).
As you can see, this would lead to an increasing number of security versions when a new minor version is added, which means more work for developers, testers and core maintainers. Besides, a large number of available releases (think 7.0.4, 7.1.3, 7.2.2, 7.3.1 and 7.4.0 being released the same day) could lead to confusion as well, which sets us back to square one... I guess I haven't seen the perfect solution yet.
we always include previous versions
The idea of security-only releases is not to have a whole branch of security-only fixes from 7.0 onwards, never including any other bugfixes. The idea is to give you a few weeks to evaluate the other fixes, because the next release which will surely be named 7.3 will 100% include all of Drupal 7.2. It will either include only security fixes or only bug fixes on top of 7.2 as per the current process. If 7.3 is only security fixes, there might be a 7.4 released at the same time which includes bugfixes as well as all of 7.3. And onwards.
thanks for clearing that up
OK, obviously I misunderstood how the current system with odd and even numbers works. Thanks for explaining. In that case, let's just use my previous comment as proof that it is indeed confusing the crap out of me :-)
So if I understand correctly, a major.minor.security system could look like this:
The rest of the universe
Well, the rest of the programming universe does security point releases e.g. 7.0.1 VS 7.1. I think by doing this, we'd just be enforcing a standard on drupal that already exists in the real world.
Do you have examples of this?
Do you have examples of this? I'm not sure I've seen that so consistently.
knaddison blog | Morris Animal Foundation
I've noticed many projects
I've noticed many projects follow semantic versioning. All of the node.js community seems to be as well as many ruby projects.
Edit: as noted earlier Django seems to be using this as well.
there's your example
There is your unfortunate example as to why Drupal 6.21 and 6.22 are separate, and why is that we don't bundle bugfixes with security releases as suggested by some people above. Just learned about this and added it to the front page announcement at http://drupal.org/drupal-7.2 :
Yes, Drupal 7 has automated testing, but last I heard it does not have 100% testing coverage, especially not for all the environments, databases etc. it is supposed to be able to run in/with.
Make it simple
Completely agree that the current system creates way more confusion than improvements. Actually, the only positive coming out of it seems to be posts like http://www.cmscritic.com/drupal-7-7-is-out-or-maybe-its-7-5-or-7-6/ making fun of it.
The second reason for why this causes confusion is that both the security and bug fix version is released at the same time, but only the bug fix is properly visible on http://drupal.org/project/drupal. That for me only gives the impression we don't take security seriously enough.
Most suggestions of change seems to bring back x.y.z for security fixes. I am pro that too since it would make it very simple to distinguish a security release from a release that also contains bug fixes.
So, my proposal is:
It also needs to be accompanied with information on the project and download pages for Drupal Core. On the project page, a highlighted box above the Download section listing the latest security fixes, with links to the SA's for each will give users the right information.
The top Drupal Core section on the admin/reports/updates page, should also list both the available security fix for the installed version, and the latest bug fix version. That way, site administrators will have access to all needed info required for their update procedures.
I believe something like this would both get rid of all the confusion, and make it very easy to know what is a security fix and what is a bug fix.
--
/thomas
T: @tsvenson | S: tsvenson.com
Just in case folks weren't convinced that people hate this ;)
See the entirety of comments at http://webchick.net/node/91
See also frequent Twitter comments like this http://twitter.com/#!/zugaldia/status/96747687570972672 and http://twitter.com/#!/zugaldia/status/96751447722569728
The issue above to allow 7.0.1 in addition to 7.1 was marked as already working by dww. This indeed seems to be what users expect.
Probably the next logical step would be to test it with all the various dependencies (Update Status, drush, packaging script, etc.), and make sure x.y.z works for both core and contrib.
Yes, to make it work for contrib too
Brilliant plan to also make sure it can work with contribs as well.
I can see it will require some work to get various parts of the infrastructure and modules work with this, but once it is done I am convinced it will be appreciated by everyone for its simplicity and clearness.
--
/thomas
T: @tsvenson | S: tsvenson.com
examples
Let's assume big bugfixes increment the middle digit and security the last digit. So this week, we'd have seen 7.5.1, 7.6 and 7.6.1 respectively while 7.5.1 would have been a security release, 7.6 a bigger bugfix on top of 7.5.1 and 7.6.1 would just be a minor bugfix from 7.6? Is that the proposal for "simple and clear"?
Or if its security releases that increment middle numbers, not bigger bugfixes then it would have been 7.6 (security), 7.6.1 (bigger bugfix pack) and 7.6.2 (very small bugfix pack)? Is this the simple and clear version?
If we use -security for security fixes but no 3rd number (one of the ideas above), then we'd have seen 7.5-security, 7.6 and 7.7?
If we also have 3rd numbers, 7.5.0-security, 7.6 and 7.6.1? If this simple?
I'm desperately trying to find a simple pattern here, did not manage to do that yet. It does not seem like we can avoid documenting what we do, writing clearer announcements (I do think that Drupal 7.7 downloadable from /drupal-7.6 is not good) and people actually reading what we write. Looks like to me regardless of the version numbering we choose, the sequence of releases we had this week would have been as confusing if not more confusing.
Right now we at least have simpler "autoincrement" version numbers, so I know at a very quick glance which one is the latest.
I tend to disagree. The first
I tend to disagree. The first suggestion "big bugfixes increment the middle digit and security the last digit" and the resulting version numbers seem very simple and intuitive to me. At least that's how most of the software I'm working with does it. And there's no way to mistake that 7.6.1 is the latest.
well
Well, is that so? This is what I did above:
7.5.1 => security
7.6.0 => big bugfix
7.6.1 => small bugfix (NOT security)
You still need to read the fine print to tell whether 7.X.1, 7.X.2, etc. is a security of bugfix release. If we use the last digit for both security and bugfix releases, then what do we really clean up? If we only use the last digit for security, then we get:
7.5.1 => security
7.6.0 => big bugfix
7.7.0 => small bugfix
Right? That is not much different to what we have now.
Disclaimer: I did not apply the numbers right either, 7.5 was released as security update to 7.4, so it should have started off of 7.4 in fact, sorry. Not going back to edit the numbers though for historic reasons.
Problem with just adding
Problem with just adding -security without incrementing any number will be when a second fix needs to be released.
My reasoning for using the z part 7.7.z as the security indicator exclusively is that everyone, and everything, will know that is exactly what it is, nothing else.
So, in the case of the "debacle" this time the release numbers should have been:
I realize that incrementing the minor for just fixing the version glitch is not optimal, but it would avoid any confusion about which version is the last security fix and which once contain other fixes as well.
Another advantage I see with this, is that it should make it easier to implement, and automate, in the infrastructure and other tools (Drush, Update Status/Manager, etc...) as well since only security fixes will have the z-part, nothing else.
--
/thomas
T: @tsvenson | S: tsvenson.com
Security fix, bug fix, release glitch fix
In an ideal Drupal world, we should have only:
But no one is immune to a release glitch that needs to be fixed ASAP (either version number not updated or a file missing).
I still believe that a release glitch fix should have a minor revision number.
But, nevertheless, if only security fixes have minor version numbers, it will be much more efficient than the current system.
/* http://www.xmacinfo.com */
The problem I see with the third digit...
Making a 7.0.1 that is just a security fix is potentially misleading when the next security fix is actually 7.1.1 and includes 7.1.0 fixes rather than 7.0.2.
People might expect that they could stay on 7.0.x and get further security updates without moving to 7.1.x.
Adding a third level or dimension into the version number potentially creates the illusion that there is an extra level of branching happening just for security fixes rather than just a linear cumulative progression through 7.x which is what actually happens. The new process is just taking two steps at a time along the same linear path as before - and I think adding a third level (whether a digit or a 'security' suffix) will create more confusion - even if people might be more likely to think they understand it.
Personally I think the numbering should match the release/maintenance process, and there are effectively only 2 dimensions to the current process. Effectively the current numbering is the same as the actual process and branching method.
I don't know if I'm typical or not - but when I first struck the new two step release in 6.whatever without any warning that it was coming, it didn't throw me at all and I 'got' why it was being done.
Note: This all assumes that there won't actually be any backporting of just security fixes - eg a future security fix wouldn't become part of 7.0.8, 7.1.7, 7.2.6 etc. It wasn't entirely clear that was being ruled out - I just assumed no overworked security team and release manager would sign up for that amount of extra work :)
--
Cheers
Anton
Making a 7.0.1 that is just a
I agree its not an optimal solution, but on the other hand it would be a much clearer and easier to understand scheme than what we have today. Now you have to search for the info about which version contains only security fixes. If you haven't kept your Drupal sites updated at every release, finding the version you need that complies with your update policy would then require visiting quite a few release notes pages.
However, I don't agree there is a big potential misleading problem by adding Z for security fixes. 7.0.1 will, by this proposed scheme, only contain security fixes for 7.0. 7.1 will contain both the security and bug fixes, thus require a bump in the Y number.
A link in every release note to a page that explains this would for most webmasters only have to be visited once so they know how it works since its so simple.
--
/thomas
T: @tsvenson | S: tsvenson.com
Doesn't help
Well that's the point. If you're multiple versions behind, there will likely be no way of just getting security fixes as there is no 'branching' going on as a third digit would imply.
You'll only be able to avoid the non security bug fixes from the very latest release - you will get all the intermediate non security bug fixes rolled up into that latest security fix anyway. In that case you'd need to test everything anyway, so the choice of which version to use becomes moot.
The security releases are only temporary breathing space for testing the other bug fixes IF you were ALREADY keeping up to date with all updates previously.
--
Cheers
Anton
You are wrong. It's not an
You are wrong. It's not an illusion, it actually maps more to reality.
In Example World, I've got Package 2.5. I have 5 commits that are not in a release. A security fix comes along, after those 5 commits. I make a branch of 2.5-security and apply that. Then I release 2.6 off of...2.5 security. And then I release 2.7 which has commits that predate the one commit in 2.6.
This is not linear.
Sure, the commit sequence isn't linear
But the numbered release are linear from the users perspective. Unless they're using unreleased code, they don't care about (or even know about) the order of commits not matching releases.
From the release downloading users point of view, each new minor release has all the changes contained in previous releases plus some new ones.
As far as the user can tell in your example 2.7 is 2.6 plus some changes, and 2.6 is 2.5 plus a security fix etc.
The codebase is not diverging, just sequentially improving each new release regardless of what order the commits happened behind the scenes or what branch they were made in.
Unless you're saying that your 2.5-security branch continues to spawn new 2.5 specific security releases for some time after the release of 2.7?? That's where an x.y.z system would be clear to end users.
Note: I'm not defending the two step security process (I personally don't need it, and can see how it could confuse some), just trying to point out that trying to map an x.y.z numbering system onto what amounts to a x.y linear sequence isn't actually clarifying anything to the end user.
--
Cheers
Anton
Of course, this only works if
Of course, this only works if you basically require every contrib maintainer to always release -dev at the same time as a security release.
Since we basically get a constant barrage from certain security professionals when we do not release security fixes in a timely manner, this means that we are forced to release -dev when we may not be ready, in order to match core's system.
I cannot tell you how strongly I disagree with this policy.
-dev versions
You are arguing contribs are forced to release a version with bugfixes as well because people were using the unreleased -dev version (or git checkout) and they expect all fixes in that version included in the release? Or is it that the social pressure of people saying if the bugfix was committed since the last release, then why it is not in this release?
This release scheme is highly
This release scheme is highly unusual compared to what I've seen in other projects. It makes more sense to me if we were to have the regularly scheduled maintenance releases (currently monthly, but may change down the road), but also allow for security issues to break that release cycle if there's a critical issue that needs to be addressed before the scheduled release. As for version numbers, it is rather unusual that Drupal uses x.y for maintenance releases, as many other project typically use x.y.z. However, it seems like many of the projects that use x.y.z typically use the y releases to add functionality that does not break majorly from the main x branch (think Firefox 3.5 vs Firefox 3.6), and then use the z releases for security and bug fixes.
Strange discussion
Lots of this discussion feels like building up something kind of false and then attacking it.
Here's what I know.
Views 2.11 had a security flaw. We were forced to release Views 2.12 as a security release. I did not feel -dev was ready, so I did not release 2.13 at the same time.
Some 30 issues appear over the next few weeks of people complaining that this, that or the other commit didn't make it into Views 2.12, for the following reasons:
So everyone assumed 2.12 should have anything in -dev that was committed prior to that date. Which it did not.
So now dereine has been playing leapfrog with issues and the number of point releases is ballooning and out of order. And this is madly confusing.
All because
securitysome people seem to be allergic to having a x.y.z?I don't get it.
I'd like to point out Gabor's hypothetical:
In a discussion about security and point releases, out of nowhere he introduces small bugfix and big bugfix. And of course, the introduction of these two differentiated bug fixes completely adds confusion and his entire argument against a .z release is this thing he introduced in that very argument.
Really? Am I the only one that sees right through that argument tactic? That's an argument tactic that politicians use to convince people who already agree with them and trick people who don't.
Edit: Changed 'security' above to 'some'. Freudian slip. I meant 'some'. I admit I was thinking security but it is not a valid argument to say that, and I shouldn't have let that one get past my fingers. Left the original word in, but I apologize to the security team for any implication.
interesting
Funny thing, this is not at all hypothetical, and definitely not my hypothetical. I merely responded to the thread in which @webchick linked in her blogpost above and referenced all her comments to read, which documented what happened with the "big bugfix", "security fix" and "small bugfix" problem in Drupal 7.4, 7.5, 7.6 and 7.7. Granted, the terminology in the comments there were "bug fix", "security fix" and "glitch fix". I've used size denominators "big" and "small" to make it easier to understand I hoped.
I like it the way it is
I'm a site-builder who hosts all my clients' sites, about 20. I think the current system is very easy to understand. I'm happy with the current system.
Shai Gluskin
Content2zero
Semantic Versioning
Yes, please! http://semver.org