Article on how we should not repeat Wordpress's mistake:

https://medium.com/@CiPHPerCoder/stopmullware-on-the-security-of-27-of-the-websites-on-the-internet-298a7e5b6871#.595l0mq0y

[now deleted]

Generally I'd like to see lots of unit tests, covering all the compo.sr APIs, to make sure things don't accidentally get broken around making releases.

See comment(s) here for possible additional considerations:
https://compo.sr/forum/topicview/browse/deploying/rolling-releases-in-v11.htm?post_id=5997&redirected=1#post_5997

"People using the hypervisor are not expected to do any custom programming or themeing (except for settings and theme images)."
Seems like a lot of work for what may be the exception to the rule. It didn't take me long to start messing with forces I didn't fully understand. Perhaps a survey on this would be useful.

Right. The only way we can really do automatic upgrades is if we know users are not overriding things.
For now this had already been pushed back, it's no longer on the v11 roadmap.

tut_software_feedback now references the desire for automatic upgrades in the future. It'll need to be updated once they are implemented.

One thing I've learned recently is the power of simple off-by-default feature flags.

New functionality: Build new functionality, only enabled if the feature flag is on.
Change existing functionality: copy and paste into a new copy of the code, and only use the new if the feature flag is on.

This would be a realy effective way for us to move towards stable rolling releases.

2025 update:

Server API cleanup
==================
I've been working on this and took a different approach. I standardised hooks/endpoints (with authorization support) so that they can be used outside of the Composr Mobile SDK. And I migrated almost all homesite API calls as endpoint calls (v11 starts using these on composr.app).

Telemetry is now also done through this API instead of e-mails. Every (unique) relayed error also gets a GUID so webmasters can check the status of their errors on composr.app.

---
"Take off the upgrader block from news posts, make those news posts strictly only for news about the releases.
Upgrades would usually only be through the JSON API which the Composr upgrader would directly communicate with."

For now, I will not do this and will leave the block. It is very useful especially if someone needs to upgrade to a specific version first before upgrading to a later version.

"Remove the descriptions ("this is the latest version" etc) from release downloads. The API should be able to find out what the latest release is just by looking at version numbers."

Actually, I plan to use the advanced feature in downloads where you can specify a file of a newer version.

Release scripts cleanup (build API)
===================================
Will probably not implement the FTP idea at this time; too much work for not enough benefit.

Upgrader cleanup
================
"The upgrader would be able to upgrade non-bundled addons."

This is dangerous as non-bundled addons can break the site between major versions. Furthermore, we decided the upgrader should not upgrade that which is not officially supported. However, I did modify v11 so the upgrader runs in safe mode, and furthermore you can go to the site in safe mode and update non-bundled addons in safe mode.

Hypervisor
==========
Not going to go in-depth right now but I did want to say originally we decided this concept would be too risky to implement (if composr.app got compromised, then automatic updates could send malware to other sites).

However, the new Telemetry service involves public and private key pairs both on the software level and the site level. It would now be theoretically possible to use these to stream encrypted automatic upgraders to people's sites using their site public key and the software private key (which is then decrypted by their site using the site private key and software public key). Even if a hacker compromises composr.app, they would not be able to stream malware through the upgrader without knowing the private keys of every individual site running Composr. And Composr does a quick site validation challenge to ensure when sites register themselves with telemetry, they are who they say they are.

This, of course, requires telemetry to be enabled. But if it's disabled, we assume the webmaster wouldn't want automatic updates anyway as that violates the core principles of autonomy.

Maintenance scripts
===================
"Enhance the scripts to not require a master password if the backdoor IP setting is set against the current visitor (including the hypervisor)."

Bad idea (e.g. multiple devices on the same IP). Instead, the maintenance password should be commented out / changed to a different one which we know what it is.

Rollbacking a release
=====================
We should take care with this. Our new developer policy should be NEVER to re-use the same version number again as soon as it went public, even if we later pull it, just in case someone upgraded to it. As such, if we roll back a release, the download should remain in the system (not validated) or some flag made so that the upgrade system skips it. And we use the next patch number when we fix the upgrade instead of re-using the same version.

Language packs
==============
"Let's just have language pack addons re-generate nightly automatically from Transifex."

There aren't updates that often. Let's do weekly instead. Nightly may be annoying for some users.