We've had this discussion in the past: http://groups.drupal.org/node/1557
Starting this thread was prompted by an overly harsh comment I made in response to walshtechnet. Here's his post:
I have been holding off on commenting on this thread as I thought it was more appropriate to let the technical community members resolve the specific issue. However, now that action is being taken, I want to address the white elephant in #38 - the 5 year D8 critical uncertainty argument - as it continues to crop up in conversations with friends in the Community (particularly those related to this thread).
From my perspective, if Drupal is going to continue to attract new users while maintaining existing ones, D8 clearly cannot remain in development for five years. I therefore feel strongly that we (as a Community) should shy away from justifying positions on any core topics based upon the length of time it has taken to release D7.
In fact, the whole notion of whether 2 years is too long is itself a subjective point that too often is taken at face value in our Community. Having worked on product teams at major software publishers and in a federal public sector business development role, I have grown to appreciate the need for software vendors (and by extension open source communities) to adhere to regular release cycles in order to be successful in a competitive enterprise marketplace. For enterprise stakeholders (an important group of end-users within our own Community), continuous innovation and release of platform products can be extremely disruptive - particularly in environments where compliance standards are paramount - because it undermines the business rhythms of the organization. This is why some software vendors rely on service packs to augment individual patches - they provide an opportunity to bundle patches that substantively evolve a platform product post-release while at the same time limiting the number of major releases for each generation of the product.
I therefore would argue that the Drupal Community should prioritize moving to more consistent release cycles which include "service pack releases." This would help Drupal core, as well as downstream software publishers (who are creating distributions), be able to better sync product innovations with the realities of enterprise deployments - especially for large government organizations who face costly security accreditation requirements. I believe that if such an option existed - and could be adhered to (a separate conversation), D7 SP1 (which would be scheduled for 9-12 mo post-release) would be the perfect option for some (#2; #4) of the challenging issues confronted in this thread.
* Before anyone comments, this thread clearly is not the place to discuss the points raised in this post - they are not core to this issue. I just wanted to throw these ideas out because I think this specific issue provides a nice inflection point for such an exchange. Ultimately, it is my hope that our Community completes a thorough review of this issue as part of a postmortem on the D7 release (conducted AFTER it releases). I believe it would help us to explore whether major SDL process changes for D8 could be undertaken that provide better options for insertion of important 11th hour issue fixes than D8.1-20 or D9. Any option would be better than having such important issues like these debated at a similar stage of D8. :)
Sorry walshtechnet, let's have a longer discussion about this here.
Comments
Enterprise
@walshtechnet - your comment pushed a lot of buttons for me. The notion of service pack releases make me think enterprise-like, Windows-like service packs. And that worries me.
Heading over to Git, I can see production Drupal sites running off of Drupal core "head" in some way. These could be considered forks, but the way git is structured, forking is GOOD. We can see the fantastic Darwinism of Drupal potentially moving even faster with git.
And, organizations like Acquia will maintain more long term stable releases for those customers that need / want that.
Perhaps you can add some more detail on how you think this is going to work. 9 months seems like a LONG time. Unless you mean back to Drupal 7.1 style of releases, and we do Drupal 7.0.1, .2, .3 etc. etc. as security / bug fix releases.
Release cycle process
I think that this discussion is more about the process of how feature updates are handled within releases and that this is not directly related to Git.
In my opinion, it is not affordable for the most of the websites running on Drupal to have 19 times to update Drupal within a major release. (And we are talking only about Core here).
Of course security patches should be issued as fast as possible. This can be handled with security patches outside of version updates. However, I think the functionallity updates should be bundled into fewer, comprehensive update releases within a major version - especially if we want to have shorter release cycles for major versions.
Generally, it doesnt look really good if we have 19 versions of the same software. As the CEO of a consulting firm, I see that a lot of my clients have a problem with that. So, this is something we need to address in D8 if not D7. If we want to sustain and grow our user base, we need to eliminate the need to explain that you will need 19 more updates until the next major version.
-----
Drupal Development by Trio Interactive
How does it not look really
How does it not look really good if there are 19 point releases between versions? Would you prefer if we saved up security patches, and only updated 5 times between versions?
New Drupal point releases are made when there are severe bugs or security issues that need to be fixed. If we do less point releases, that just means we are not releasing major bugfixes and security patches as fast as we should be.
Lots of point releases is a result of active maintenance of a large project. If a client doesn't want to upgrade along with core, then they just have to accept the fact that they will have a buggy and insecure site. Keeping your website secure is part of running a website; anyone who expects any less is fooling themselves.
Edit:
Further, releasing security patches outside if point releases is a pointless issue - what is the gain? The client still needs to update their site, whether they execute a patch or unzip a new release tarball. Arguably, the patching the core tree requires more user knowhow than uncompressing a release tarball.
Brian Vuyk
Senior Developer, PINGV Creative
bv@pingv.com | (315) 849-9733 | Skype: brianvuyk
Quick Response
It is interesting to see this conversation spouting up. I will respond to the main thread conversation by the end of the week. In the meantime, I do want to address this side issue though. The point that I was trying to make was in relation only to functionality updates – not security patches. This is an important distinction. I do not think that anyone is advocating not patching security updates. The proposal (which is not a new one) simply is that these are handled as 7.x.y releases. The 7.x releases instead would be roll-ups of all of these security patches as well as any major functionality updates that might be required (so long as they preserve API compatibility). These would be the service pack releases that I am referencing. Both the module and distribution maintainers could voluntarily elect to align their functionality releases (which we all know sometimes are being distributed within security updates) with these scheduled service packs. This in turn would enable more efficient and economical updates to end-user websites. It also would provide an opportunity for core updates (such as #2 and #4 in the distro discussion) to be included prior to D8. This hopefully would make it easier for the Community to resolve critical issue debates where the issue is only critical because the affected parties cannot reasonably be expected to wait until the next generation release for resolution. Ultimately, this could streamline the release of D8 so that we do not see a continuation in the length of time between generations of the product.
I've been trying to figure
I've been trying to figure out what you are suggesting, and I can't make sense of it in any way that resembles something which could be beneficial to any segment of the community.
I don't see the supposed 'important distinction' between functionality updates and security patches, because there is no such distinction in Drupal's release process. When a security patch or critical bug fix is committed to the D5, D6, or D7 tree, a new release is rolled with the important patch, and all previous patches to that tree. Note that these are bugfixes and security updates - not feature or API updates. We try not to do that within a major version unless there is overwhelmingly good reason to force that change on all X-hundred-thousand sites and users running Drupal. If you look at the 19 Drupal 6 point releases, you will see that of those 19, only three (6.8, 6.17 and 6.19) do not contain security fixes. 6.19 was a special case as it was released 20 minutes after 6.18, and contained the 6.18 security patch as well. The remaining 16 releases all contained security patches and bug fixes. The point being, point releases aren't made without good reason - either there is a security patch which needs to be released, or there is a bug considered critical enough to warrant it.
Each of those releases should take perhaps 20-30 minutes at most to update. Certainly less then doing a round of updates of contrib modules (which have their own security patches). I don't consider it an unrealistic expectation for someone, especially a large corporation, to invest a half hour once or twice per month to keep their site secure and up to date. Regardless of whether a patch is just a security fix (as it would be under your plan), or security and non-security bug fixes, the amount of time to update core will remain the same. As will the number of releases that you will have to apply to remain secure.
In short, if you find that the time and effort of patching core once or twice a month to be more valuable than the possible ramifications of people exploiting published security holes in your sites, by all means, update your website less often.
Brian Vuyk
Senior Developer, PINGV Creative
bv@pingv.com | (315) 849-9733 | Skype: brianvuyk
Clarifying the point
Regardless of the current state of affairs, I believe there SHOULD be feature updates between major versions so long as such changes preserve API compatibility. If such an option existed (through a service pack or otherwise), then there would be a way to resolve some arguments (perhaps the distro debate which this discussion branched off from - assuming that #2 or #4 in that thread could be resolved in a manner that preserves API compatibility). In the absence of such an option, the only available alternatives are to either define such fixes as critical issues and delay the release or push the changes to the next major version. The result is an argument over two options which either party finds unpalatable. How would it not be beneficial to create a compromise for these sort of issues? It certainly would help the Community confront a variety of issues (although certainly not all issues - since some will break API compatibility) which could cause the delay of D8 and future major versions.
Furthermore, such an option would help module and distro owners to voluntarily align their major feature updates to an agreed upon release cycle. While there might not be a lot of feature updates to core, there are to the ~7,000+ modules out there. These sometimes occur alongside security updates, which itself is an issue. The proposed changes to the core release process are as much about thought leadership as anything else. This would help end-users who would then have a milestone for intragenerational functionality/feature updates across their site.
At the end of the day, this is not about security updates so I would ask that we not continue to discuss that point. The argument that you are making on that front is probably accepted by everyone on this thread. :)
(Disclaimer - These are my personal views and not those of my employer or colleagues.)
These are API updates
Usually the stuff that people want changed actually are API updates. Which means 7.4 (for example) would require contrib module updates. Which basically IS a full release. Sounds like you want to go back to the 4.x days -- where "smaller" point releases really were full updates.
Can you try and spell out more plainly what you're proposing?
The matter of multiple releases
I am writing this in Safari, which despite being a quite recent release, is already on 5.0.2. My Mac is on 10.6.4. Mail is 4.3. Firefox is 3.6.8. Tweetdeck is on 0.35.3. MAMP Pro is 1.8.4. Balsamiq is 1.8.12. I could go on. My point is that software undergoes updates — and quite frankly, I prefer the ones that continue to update bugs rather than let them build up for a long time. Especially with open source projects. Show me an open source project that updates its core software only once or twice a year, and I'll show you a project that may be losing momentum or achieving stagnation. I don't think Drupal would be served by letting bugs linger for months after patches are committed because creating a new release somehow looks bad.
Isn't the real issue the smoothness and pain-free character of a point release update? In the past 6 years, I've seen Drupal only get better regarding this. (Contrib modules can be hit or miss, depending upon the developer.) A general policy clients often adopt is to skip the point release if it does not address a relevant security issue or particular bug they are experiencing.
PINGV | Strategy • Design • Drupal Development
Big numbers make people nervous
You may notice that it's extremely unusual for release numbers (except the first, major) to get over 10. I'm not sure why, but I have certainly noticed that it makes people nervous (and/or they poke fun at it) when the numbers get over 10. It would be a good idea if, for a start, all security-only and most bug-fix-only releases were given a two-dot release number (like 7.0.1). We'd have the same number of releases, but the numbers wouldn't freak people out. (Silly but true.)
But seriously, Drupal updating leaves so much to be desired compared to ANY of those products you mentioned.
I have given several people copies of a list I wrote called "Updating Drupal for Smarties", which is basically a translation of the advice on this website into a reasonably succinct UNIX-specific set of 15 steps that works pretty much every time, and takes under a half-hour. How much do you see that is wrong with that? (Hint: how many steps do you need to do to update Firefox, how long does it take, and how often does it go trouble-free? Now consider that Firefox is a much larger and more complex piece of software than Drupal is.)
Saying that Drupal's update is better than it ever was, although true, is irrelevant. It's very intimidating to many people, and I'm talking about people who know how to program, at least at some level.
I'm not sure what the solution is, but the problem should be obvious to anyone willing to expose their head to the light of day: Drupal does not have a reliable 1-click update that works regardless of the existing version, and it needs one desperately. Just like Safari, Mail, Firefox, Thunderbird, etc. Heck, even Windoze has a 1-click automatic update!
It's not rocket science: in theory, it would go something like this:
WHILE current version is < newest version (within same major version):
. . DETERMINE the next version after the current one (from a list on Drupal.org)
. . DOWNLOAD the update for each contrib module to the next version
. . DOWNLOAD the update for core
. . UPDATE everything
. . TEST if it went right (if not, bail)
I don't think this would require changing the way update scripts are written now (except maybe they'd have to be more reliable). It just requires an update module to be added to core and supported by the site so it can find everything, no? It seems that the trickiest part would be testing it on all the different OSes, and beating on those contrib modules that don't update well.
Truthfully, I don't understand how 7 could come out without it.
Would it be considered "twisting the knife" if I said that I think Wordpress has a 1-click update now that works?
Try Drush, particularly
Try Drush, particularly "drush up" - by answering a few prompts, you can actually do what you've suggested here in terms of upgrading. It does a good job and will even update your contrib modules.
WizOne Solutions - https://wizone.solutions - Drupal module development, theme implementation, and more
FillPDF Service - https://fillpdf.io - Hosted solution for FillPDF
Quite glad
Hi Boris,
I'm quite glad you opened this thread:
- it gives us a good place to discuss this (indeed, the original post was a bit off-topic, but it was worth starting the debate)
- it shows the strength of our community: people sometimes disagree, exchange with passion (which may include a bit of harshness), but always mean to work together for the good of Drupal
"Segments" pretty much stated my feeling. Talking about "Drupal 6.19" can be quite shocking. I think we should afford clearly identified steps through a version.
Checking the Drupal 7 critical bugs list many times a day, it seems obvious that people feel like there will be many years between Drupal 7 and Drupal 8. And once the decision is taken to move an issue to "8.x-dev", it makes everybody feel quite bad... We should be able to release a stable Drupal 7.0 and improve its functionnalities by packs every few months (9 ? 12 ?). Security patches would be handled in parallel, of course (7.0.1 and so on, as you said).
Laurent Ajdnik (Drupal Lyon)