53 Comments


  1. Can we have accurate reporting please?

    The fact that it’s security releases only is a very important distinction here

    would be an important distinction, but its not true. Its all minor updates, not just security updates. There is no way to select ‘security releases only’.

    Reply

  2. Thank you Sarah for the info.

    I will take your advice and not be “lame”;) disabling the security and minor releases.
    A question. The Relevanssi plugin broke when updating to 3.7 . Does this mean, that it “raises a red flag and a few questions about how that plugin is interacting with the WordPress core”?

    Steve

    Reply

  3. @Steve Moss – One of the improvements to WP 3.7 is improved search results and so that is likely a conflict with the Relevanssi plugin and you may want to disable it until the plugin author can update his plugin to not conflict with 3.7.

    Reply

  4. One thing I’d like to see is the ability to update core on milestone releases, such as Beta-1, Beta-2, RC-1, etc. So, essentially: core would stay at the most recent major/minor version, until a beta or RC is tagged, then update to that milestone. All other nightlies/dev updates are ignored.

    I would use such a scheme for keeping development installs (such as what I use for Theme/Plugin development) up-to-date, and to perform beta-testing of Themes/Plugins concurrently with core.

    Perhaps:

    define( 'WP_AUTO_UPDATE_CORE', 'milestone' );

    or:

    define( 'WP_AUTO_UPDATE_CORE', 'prerelease' );

    Reply
  5. Wilson

    Hi

    Just wondering how this new feature will impact translations as the translations teams around world sometimes take a few more days to get the files ready.

    Any thoughts?

    Thanks Sara

    Reply

  6. @Wilson – Yes you should be able to get translations faster now. WordPress 3.7 now has the ability to install the right translations files and automatically keep them current in the background as well.

    Reply
  7. Wilson

    @Sarah Gooding -

    Thanks Sarah

    So let´s imagine that in the case of a e.g 3.7.2 minor update, with a few translation strings changes or added, ok? What will happen if translation files aren´t updated by the team?

    Reply
  8. Kurt

    It will be a cold day in heck when I allow machines to push changes to production servers with 0 testing on a stage machine. I’m not waking up in the morning to an east coast client telling me their B2B ordering system is down and “what the heck id I do to break it”. “Oh, sorry but what I didn’t tell you is that I outsourced security and patching maintenance to a bunch of magic elves. They said everything would be well tested first.” doesn’t make a good answer.

    Maybe it is because I came out of the entertainment and online games industries but I believe it would be obscenely irresponsible.

    Kurt Flint
    Sometimes Consultant
    (and CTO of the stock watch index group)

    Reply

  9. @Kurt – Hey to each his own. Gotta love the freedom to turn it on or off. I’m just loving the mention of “a bunch of magic elves” in this comment. ;)

    Reply

  10. @Chip Bennett – Love that idea. I’m about to get started on my first theme to release in the repo, something like that would be extremely handy as I go along. +1

    Reply

  11. @mike finley – I was thinking about this earlier today. A 3.7.1 release can either be a minor release, security release, or both. Over the years, we have described them as two different updates but both up the version number the same. You can’t call it one or the other because some of the minor upgrades are just typical maintenance releases. This is something I’d love to hear Andrew Nacin lend his wisdom to.

    Reply


  12. @mike finley – Correct, it’s all minor releases. In practice, minor releases are rare. The .1 release will always be needed to fix some bugs. Pretty much all others are security releases. Sometimes, the .1 also contains security fixes. A .2+ release is only going to happen for security reasons if there is a serious regression that somehow wasn’t discovered before the .1 release (which implies it probably wasn’t that serious).

    Generally, then: .1 is a minor release with serious bug fixes. .2 is a security release and/or a critical regression fix. If you’re on 3.7, you’re going to want a regression from 3.6 fixed on your site. There’s really no reason to decline either of those releases. No, there is no differentiating in terms of how we version them, and we don’t plan to do so.

    Finally: We have the ability to push out a minor release without having it auto-updated. We also have the ability to slowly roll out auto-update instructions. Essentially: We have a lot of tools at our disposal to ensure your site is getting exactly the fixes it needs. For more on this, read the definitive guide I wrote. I also talk about how this might mean more frequent minor releases, but that might just mean that .1 might be less of an omnibus release four to six weeks later, and is instead only a week or two later with a few important bug fixes.

    Reply
  13. Kurt

    Before wandering by to see what people’s ideas and opinions were I had already disabled it in the on all of my server configs, doing it now though I had only installed the update on my multi purpose test machine yet and will not be putting it onto any of the staging machines until their daily checkup in the evening (we do continuous build, but things that require human intervention get saved for the last overview of the day). I will probably then let the stage machines sit and marinate over the weekend, and if we like the look of things on Monday, and stuff we wrote ourselves still pass PHPUnit testing (and a quick sniff with a code smells detector doesn’t think 3.7 is fatally flawed which would surprise the heck out of me if it did), Tuesday morning some people will get a memo mentioning the latest changes and features and reminding them of my personal cell number. I won’t upgrade more than one or two a day so that there will be minimal risk I’ll be having to have one client hold for another’s call, or worse be letting anyone go straight to voice-mail!

    Hopefully that way my elves and I will stay on everyone’s christmas card list ;)

    Looks nice and shiny by the way!

    @Andrew Nacin Thanks for the definitive guide link. I am glad I checked to see if anyone had posted something interesting while I had been writing. I almost missed it!

    Reply



  14. Hi Sarah
    “The fact that it’s security and minor releases only is a very important distinction here.”

    Thanks for pointing that out.
    I was going to disable automatic updates, but that has changed my mind.

    Reply
  15. Neo

    Hi Sarah,

    Lol, i have bulletproof security running and it has the option to restore any changes in files in the root. It also write protects those files. So this is their way to prevent the website from being hacked. That will create a big mess after wordpress updates.

    I will setup a test server to see what the outcome of that will be. This could become very funny.

    Best regards,
    Neo

    Reply

  16. So I’m still a little confused on the what is considered “minor”.

    Clearly minor is not getting me the development releases.
    Minor will get me 3.7.1 (right?)

    But will minor updates get me 3.8? Is a 0.1 upgrade “minor”?

    I’d think a jump from 3.x to 4.0 would be considered major…?

    Gary

    Reply

  17. When you say “on by default” makes me think that even if

    define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

    isn’t in my wp-config.php file, it’ll still update automagically. Correct?

    Or do you just mean that in new installations that line of code will be in new config.php files?

    I just updated one of my sites and see that like of code is not in the wp-config.php file.

    Thanks!
    Gary

    Reply

  18. @Gary LaPointe -

    So I’m still a little confused on the what is considered “minor”.

    Clearly minor is not getting me the development releases.
    Minor will get me 3.7.1 (right?)

    But will minor updates get me 3.8? Is a 0.1 upgrade “minor”?

    I’d think a jump from 3.x to 4.0 would be considered major…?

    Saying that a jump from 3.x to 4.0 is major would be a version schema where X is a major update, and X.Y is a minor update.

    That’s not how versioning works in WordPress. In WordPress:

    X: no such version
    X.Y: major
    X.Y.Z: minor

    So, there is no such thing as WordPress Version 3, nor will there ever be anything such as WordPress Version 4.

    Major WordPress versions are 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, and soon: 3.8.

    Minor versions are 3.6.1, 3.7.1, etc.

    And here’s the kicker: versions 2.9, 3.0, and 3.1 are all equally major versions. Likewise, versions 3.9, 4.0, and 4.1 will all be equally major versions.

    This is a common point of confusion – and, I suspect, perhaps a contributor to some people not updating from version X.0 to version X.1 or later.

    Reply

  19. @Gary LaPointe -

    I just updated one of my sites and see that like of code is not in the wp-config.php file.

    WordPress neither creates on install nor overwrites on update the wp-config.php file.

    The easiest way to control the settings would probably be via Plugin. There are already a few in the Plugin directory that will expose UI to configure the various settings.

    Reply


  20. Jimmy

    I update to 3.7 and today WP told me there is a new version available : 3.7.1, auto-update doesn’t works?

    Reply

  21. @Chip Bennett – Actually – it’s possible to stay updated with beta and nightly builds. It doesn’t come with core – instead you have to install the “WordPress Beta Tester” plugin – http://wordpress.org/plugins/wordpress-beta-tester/ .

    It’s not a big hassle to install the plugin and happily use the latest development releases(of course you can also use version control to directly update your core files with Git or SVN, but that’s a different story).

    I believe that this specific plugin should not be merged with core – if you’re a developer and want to stay up to date with the latest WordPress builds – then you install the plugin. Normal users should not have that option out-of-the-box in my opinion.

    Reply

  22. I recently updated to 3.7, and just double checked my wp-config.php and I dont have the line:

    define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

    Reply
  23. Bridget

    Thank you for the blog post.

    I am working with a business owner and it seems that she hasn’t done ANY updates since 3.0.5 … I know to back everything up… but are there any concerns about going from 3.0 directly to 3.7.1?

    Thanks
    Bridget

    Reply

  24. @Chip Bennett – Nice idea for sure. I don’t think we’d need to actually introduce a new value for that. Running a development version is enough to receive auto-updates to that branch. Unfortunately, that means you automatically “skip” to the next branch (so you’d go directly from 3.7-RC2-golden to 3.8-alpha). I actually prefer that, because it means people continue to test trunk, rather than us losing our body of testers each release. What actually should happen is the beta tester plugin should give you a proper choice: Do you want to just test 3.7, or do you always want to be on the bleeding edge? This is something we intend to revisit in 3.8.

    Reply

  25. @Nikola Nikolov -

    Actually – it’s possible to stay updated with beta and nightly builds. It doesn’t come with core – instead you have to install the “WordPress Beta Tester” plugin

    Yeah, I’ve been using Beta Tester for a long time now. :)

    Beta Tester basically lets you choose between point releases and bleeding-edge nightlies. One would think that a Plugin named Beta Tester would include an option to update to release milestones such as Beta and RC.

    Its functionality is essentially part of core now, with the available filters. But both core and the Beta Tester Plugin miss a key demographic: Theme and Plugin developers who need/want to start testing for compatibility at beta, and not before.

    @Andrew Nacin -

    I don’t think we’d need to actually introduce a new value for that. Running a development version is enough to receive auto-updates to that branch. Unfortunately, that means you automatically “skip” to the next branch (so you’d go directly from 3.7-RC2-golden to 3.8-alpha). I actually prefer that, because it means people continue to test trunk, rather than us losing our body of testers each release.

    I don’t mind being a core bleeding-edge tester. But I’m a small-time developer, and even I have a dozen Plugins, plus a Theme to support. I don’t have time to try to monitor them throughout the development cycle. APIs change, things break, and although nightlies tend to be generally stable, they can cause a lot of unnecessary re-work for Theme/Plugin developers trying to keep their code compatible. Milestone releases – betas and release candidates – should have APIs stable enough that it makes sense for Theme/Plugin developers to make compatibility changes at that point.

    It is standard practice (in any software project) for extension developers to begin compatibility testing at the beta stage. IIRC, it is even (or used to be) MO for the beta and RC release updates from make/core include a request for Plugin/Theme developers to begin testing their code against the release. It would be awesome if the core automatic update feature could account for that.

    (And I would go with a filter rather than a wp-config constant.)

    I do hope this decision is revisited in 3.8, because I think we’re missing a slam-dunk opportunity to facilitate more Theme/Plugin developers to begin compatibility testing at release milestones, without having to stay on bleeding-edge nightlies.

    Reply

  26. @Andrew Nacin -

    By the way: is there any documentation on how the various transients work together, including how often WordPress checks for updates, whether or not api.wordpress.org sends the update, and when/how often the update routine executes?

    Right now, I’m sitting here with an update_core object that has had the 3.7.1 update (since last evening sometime), but the automatic update isn’t firing. That’s being controlled by the delayed rollout, but I can’t seem to track down how all that works together.

    Reply

  27. @Chip Bennett – The 3.7.1 update offer you see in the transient is for manual updates only. The auto update is a separate offer that is only being provided to about 75% of installs at the moment. It shows as a “response” of “autoupdate” instead of “upgrade”. When your site receives the instructions, you’ll end up with not one but two offers in the transient. See find_core_auto_update() and get_core_updates() (both in wp-admin/includes/update.php) for more.

    Reply

  28. @Chip Bennett
    But NOT having the line of the code in the file mean that it’s going to do the default function, right? Which would to do be minor upgrades?

    The word “default” implies it’s going to happen regardless (of the line of code).

    Reply

  29. @Gary LaPointe -

    But NOT having the line of the code in the file mean that it’s going to do the default function, right? Which would to do be minor upgrades?

    The word “default” implies it’s going to happen regardless (of the line of code).

    Not necessarily. There are two different ways to control the automatic update functionality:

    1. Defining constants in wp-config.php
    2. Filters

    The available Plugins use the filter method, rather than the wp-config.php constant method. Both are equally effective.

    Reply

  30. I just got an e-mail from WP that says “Howdy! Your site at http://GHotos.com has been updated automatically to WordPress 3.7.1.”

    I had upgraded the site to 3.7, did not modify the config file and the config file does not have the line of code in it.

    The only odd thing is the update message is from right around the time that I logged in to check and see if it had updated. It had not and asked me to (up at the top of the screen) and I ignored it. I’m not sure if logging in possibly triggered it to update. (It’s an interesting coincidence if it didn’t).

    Reply

  31. @Gary LaPointe – No. Logging in did not trigger the update. It took a lot of restraint but I saw the upgrade message for 3.7.1 for hours on end before I actually received the email tonight, letting me know WPTavern was upgraded automatically to 3.7.1 with no problems.

    Reply

  32. @Gary LaPointe -

    I just got an e-mail from WP that says “Howdy! Your site at http://GHotos.com has been updated automatically to WordPress 3.7.1.”

    I had upgraded the site to 3.7, did not modify the config file and the config file does not have the line of code in it.

    That is as expected. The default core behavior in 3.7 is to update minor releases automatically.

    Reply

  33. All my sites now upgraded automatically to 3.7.1 without any problems.
    Doing the happy dance.

    Reply

  34. @Jeffro, @Gary LaPointe – It’s possible that logging in did trigger the update. The WordPress cron system is able to fire off scheduled tasks only when a site has been visited. It’s possible that your visit triggered the update. This is pretty rare, but certainly possible, and even something we even considered.

    Reply

  35. Great tips. That works for WP 3.7.1 as well. I have another issue. One of my sites at http://vietnammotorcyclemotorbiketours.com can’t automatically detect available update version of plugins. I set up 9 sites with the same settings and other 8 sites can display updates for plugins when available. Anyone has any idea how to fix this?

    Reply



Leave a Reply