While we were planning the upcoming UCS development stage, we decided to start working on the next major version: UCS 5.0 is planned for next year. In this article I would like to let you take a look behind the scenes and share some of our plans with you.
It’s been almost 5 years since we released UCS 4.0. During this time, UCS has evolved a lot. At the same time, we’ve continued to maintain the old version’s features. While most of them are popular with our users, others are not. There are also some things we would do differently if we had to do them again. By jumping to the next major version, we would like to get rid of some relics and implement several new features at the same time. We’re still at the very beginning, so not all decisions are final yet – but true to the motto “be open” I would like to share some of our ideas and plans in this blog post.
Changing to Debian 10 “Buster”
The new release will see an update of the base, and we will upgrade to Debian 10 (codename “Buster”), released in September 2019. In addition to all the upgraded packages, we will continue to reduce the differences between Debian and UCS in the main distribution. For example, Debian now has working UEFI Secure Boot (partly thanks to our support), so UCS no longer needs to make any adjustments.
Migration to Python 3
Most of our software at Univention is being developed in the Python scripting language. UCS 4.x uses the Python 2 runtime environment, although Python 3 has been around for quite some time. Python 3 is going to be the standard for implementations in UCS 5.0, so that we and our partners can benefit from the possibilities of the new version. You can see the first steps of this transition in UCS 4.4 as some of the packages have already been converted. Integrations or projects that make use of Python-based UCS interfaces such as UDM hooks or listener modules should run some checks until the release of UCS 5.0 to ensure Python 3 compatibility.
Hopefully this doesnt cause our server to break, and is a smooth upgrade process in order to ensure continuity in the corporate office. Disturbances in server applications are not well received, so i do hope this is a priority so that we remain with your platform.
Hi Christian,
thanks for your comments.
Stable updates are a major objective for our development. The basic update process will be the same as for example for the update from UCS 4.3 to UCS 4.4.
As this is going to be a major release update, you might need more steps for preparation and postprocessing than in other upgrades – the release notes will describe what is needed. Please expect the update to take a bit longer as the amount of packages upgraded will be larger.
Hope that fits your needs!
Ingo Steuwer
Corporate offices do not like big changes in order to add a new interface, for example. Once users learn a platform, it needs to stay relatively close or there is no ROI in here for us. it is wise to consider having to retrain users as a serious detrimet to the open source community. Users do not care about the extra stuff, only that what they are used to using is there, and does not radically change. Otherwise, it might be better to just host each app on its own copy of Debian to avoid your hassles.
Hi Christian,
thanks again for your feedback. To ensure we have the same understanding I’d like to explain a bit what users can expect from the update:
* 3rd party Apps hosted on UCS (Groupware, File Sync etc.; examples are Kopano, OpenXchange, Nextcloud, ownCloud, …): These Apps are going to be mostly stable even during an update of UCS itself. So while the underlying system gets many updates, the packages or docker container containing the App will most often stay the same or will se only minor upgrades to integrate with the new UCS version. This is the most prominent part for End Users – so they might not even notice an upgrade.
If Upgrades for 3rd party Apps are at the same time, we will try to split it to avoid situations where you are forced to upgrade both UCS and the App at the same time.
* UCS Core Services (examples are Active Directory compatible authentication, File, Print etc.): While these Apps fullfill an “everyday need” of many users, they don’t come with an dedicated interface. You might notice additional configuration options or new APIs, but our objective is always to try to stay compatible with the previous version. What will be improved is the web interface to manage these services, but as we don’t change the focus / use cases, I don’t expect prominent changes in the workflows.
* UCS Debian Distribution: The base packages will follow the normal Debian release upgrade process.
So, I fully understand your topic and we want to follow our process of continuous improvements in favor to “big disruptions” while improving UCS.
Beside that, I want to add that subscription owners of UCS 4 can expect a long term maintenance for UCS 4.4 so they will have enought time to prepare the update.
Ingo Steuwer
KDE is a curious question. Why would one want any desktop on a server? If I want a client experience, it will always be nicer on a desktop focused distro. If one is hosting thin clients, then I could see that, but that does not seem to me to be what ucs is about. I think it is better being focused on being a corporate server. Similarly, 32 bit is kinda dead too.
I like this roadmap in the broad sense. I also like that the value add is in python, and do appreciate the struggle with python3 migration. I have found myself in much the same situation with some of the things I am doing.
Thanks for your feedback!
In the past we had some feedback that a desktop environment even on a server is a good thing, for example to have a graphical tool to edit file ACLs or run a browser to open our management tools. But all feedback we got (most of it by mail to feedback@univention.de) was similar to yours – it’s not needed (anymore).