Opened 14 years ago
Closed 11 years ago
#15738 closed feature request (duplicate)
Automate Security Releases
Reported by: | ericmann | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | trivial | Version: | |
Component: | Upgrade/Install | Keywords: | needs-patch dev-feedback ux-feedback |
Focuses: | Cc: |
Description
When security releases are published, several less tech-savvy users might neglect to update in fear of breaking their site. In reality, security/maintenance releases don't change the core API and shouldn't break anything*.
We should have an option (disabled by default) that allows these X.X.1-style security updates to happen in the background. This will keep sites updated and secure and (hopefully) prevent the inevitable "I wanted to wait to install 3.0.2 and someone hacked my site while I was waiting" support requests.
The option should be disabled by default, but when users are on the update screen they should see an option to "install security releases automatically."
Major releases should always require an explicit action from the user to update the site as they can break themes and plug-ins and could potentially update database schema.
- Except in the rare occasion where a developer hacks core.
Change History (6)
#1
@
14 years ago
- Keywords dev-feedback ux-feedback added; needs-dev-feedback needs-ui-feedback removed
#3
@
14 years ago
- Milestone changed from Awaiting Review to Future Release
- Type changed from enhancement to feature request
I would love it if we could security updates automatically, but when it's been discussed before the variations in server setup etc has always been the blocker. Moving this to future release, it can be discussed in 3.2 dev cycle. Notification emails (as referenced by dd32) is something all the leads have signed off on, so that's more likely to make it into 3.2.
Also changing type to feature request, as this isn't a tiny little fix to the existing process, but an entirely new one.
This will not be possible (securely) on all installations, even if the user requested. Hosts which require the usage of FTP are ruled out straight up, as storing the FTP password is a no-no (Incase the system is exploited).
Personally I believe #10787 would be a better way of helping users update faster.