First of all, thanks for the suggestion. I'd also like to have this feature, not only to get updates rolled out more quickly, but even more to be able to easily install plugins. However, there is quite a number of concerns that I have and while I'm always open to discussion, I'm only that much away from closing this as "wontfix".
Currently, there are two official ways to install pretix: Using docker and manual installation via pip or from git. For both of them, we provide tutorials to help beginners, but with both ways, you can greatly deviate from the tutorials and there are good reasons to do so. For example, in both the docker and the manual case you could run the pretix processes (web process and worker process) across multiple machines. You could use one of the multitude of orchestration tools for docker, e.g. docker-compose or something more complex like kubernetes. You could automate your manual installation using a tool like Ansible, Salt or Puppet. You could use your distribution's package manager to install the dependencies or use pip. You could use your distribution's python version or roll your own. You could run the processes using systemd or supervisord or upstart or whatever floats your boat on Debian, CentOS, FreeBSD or maybe even Windows (haven't tried yet, but should work). There are good reasons for most of those decisions and I've seen most of them in practice. I'm a sysadmin for currently three installations of pretix that are vastly different from each other.
pretix doesn't know about most of these differences, because it doesn't care. That's a good thing, it proves that the system is flexible and it makes sysadmins of very different taste happy.
Auto-updating could only support very very few of those cases and would require us to introduce a lot of new assumptions. The docker installation couldn't use it, because it's good practice to keep docker containers immutable and our container shouldn't be able to talk to the docker host and recreate/restart itself for a number of reasons. Using a provisioning tool like Ansible would require very special care in combination with such a system. Self-updating the software in-place across multiple machines also sounds quite ambitious.
Frankly, any straightforward implementation of this couldn't properly support any of the three installations I maintain. I see this as a very bad smell, not only because that means I wouldn't even notice if it breaks, but also because it suggests that it might pose large problems to other admins. Furthermore, other people don't know the system as well as I do and might not even see that and why they shouldn't do it. I don't really like the idea of pretix installations becoming even more different than they are now.
We won't break anything between patch-level releases (except if required to fix vulnerabilities or critical bugs), but between feature releases (like 1.x.y to 1.z.0), we currently make very limited promises about compatibility to external systems. Of course, we try to make it backwards-compatible and easy most of the time, but in general, new versions of pretix might for example
- require new system-level (non-python) dependencies
- require a newer version of python
- introduce code changes that break all plugins
- require new external components (maybe redis doesn't stay optional forever?)
- require you to adjust your webserver or database configuration
- require you to adjust your pretix.cfg config file
- require you to run a special upgrade command
Some of those cases could be automated, at least for some setups, but most of them couldn't (see also: security concerns). In all those cases, self-updating could break and you wouldn't want a non-technical person or a person without access to the operating system to (accidentally) update the system. You'd want your sysadmin to be there 😉
Updating means automatically downloading and executing code, which would require great care to avoid introducing vulnerabilities here. This would be even worse with plugin installations. Additionally, even though it might be possible in most current installations, there is no reason why a running pretix process should be able to alter its own source code and it might be a good idea from a security standpoint to disable it.
For all those reasons and maybe more, I believe the automatic update check and notifications that we introduced in 1.2.x are the closest we get here. If someone wants to go through the trouble of packaging this in a standardized and isolated way like the GitLab Omnibus package and would commit to maintaining that in the long run, that could help with some of the problems above, but still not with all of them.
P.S.: You suggested on twitter to talk this through on e.g. IRC, we can totally do that, but if we keep the discussion here, people can read up on it later and it can be helpful both for me to point people to if they ask for this feature again and for other projects to learn from, so if it's no trouble for you, lets stay here.