This was originally a private chat between Pirate Praveen and Count Dracula. Published with permission from Count Dracula.


Pirate Praveen: OK so you can help with rails 6 transition. Are you familiar with transitions?

Count Dracula: I am not familiar with transitions but I am willing to learn

Pirate ‍ Praveen: No worries, I can explain

Count Dracula: Awesome! Thanks a lot. I can start now.

Pirate ‍ Praveen: In Debian we like to maintain only one version of a library like rails. But it means extra work for us because other libraries and applications may not support the version we have in Debian. So we have to port those software.

For example, gitlab, redmine, diaspora and open build system uses rails. In buster we had rails 5 and in bullseye we want to update it to rails 6. gitlab already support rails 6, but others don't support it yet. So either we wait or we help those projects to update their rails version.

Similarly we did ruby 2.6 to ruby 2.7 transition and we are currently doing nodejs 10 to nodejs 12 transition

Is it clear? Any questions?

Multiple versions vs removing incompatible versions

Count Dracula: Clear but I don't know... maybe packaging all the version and asking the software to choose which version to choose would make more sense

Pirate ‍ Praveen: That means number of packages to maintain increases We will have to keep supporting rails 5 and 6 even when rails upstream may drop support for it.

Stable support commitment

Once we ship a package in a stable release, we provide security support to it.

Count Dracula: Ah okay, that would also introduce stability issues.

Pirate ‍ Praveen: So we can't stop supporting rails 5 until we stop supporting that stable version.

For example, if there is a security issue, we will have to update two packages instead of one - rails 5 and rails 6.

Add to that, oldstable and oldoldstable (long term support)

Exceptions - when to provide multiple versions

But still for some packages we do provide multiple versions

GCC and python are examples

But each team decides whether to support multiple versions or not

Ruby Team policy on multiple version

Ruby team used to support two versions of ruby earlier but we stopped it as we could not support two versions simultaneously

Count Dracula: Got it

Rails 6 transition

Pirate ‍ Praveen: So now coming to rails 6

What we do is, we upload rails 6 to experimental and announce we will be moving to rails 6 for bullseye.

This gives every one depending on rails time to update their packages.

Sometimes upstream already support rails 6 so we just have to update the package to new upstream version.

Count Dracula: if there's some conflicts with the newer version? do we chuck it out or what?

Pirate ‍ Praveen: I did not understand the question. Like when other package does not work with rails 6?

Count Dracula: yeah, if there's some problems and the upstream don't want to fix it

Pirate ‍ Praveen: The maintainer can fix it and include a patch.

But if no one cares to fix, we remove that package has details for architecture dependent packages.

When to embed older version

In extreme cases where we don't want to remove a package, we can embed the required version.

For example if redmine does not support rails 6 by the time bullseye release, we can embed rails 5 in redmine.

Count Dracula: wait... the entire package? like the person has to download another entire version just to use that software?

Pirate ‍ Praveen: Or skip bullseye and provide update via bullseye-backports when upstream support it.

Yes, redmine becomes redmine + rails 5

Count Dracula: what if there's two such packages (pkg1 needs rails 5 and pkg 4 also needs rails 5) does the person need to download it twice?

Pirate ‍ Praveen: But we try to avoid such cases.

Yes, we could also create a rails5 package also if there are many packages that needs rails 5.

But then we end up having to support 2 rails versions which we want to avoid In case redmine embedding rails 5, it becomes responsibility of redmine maintainer to support rails 5.

So when security updates come to rails 5, they will have to update redmine.

Count Dracula: got it. So it's better to shift as many packages before the release itself.

Pirate ‍ Praveen: Yes. This is becoming harder, no doubt.

FastTrack and fast moving projects

Especially for web based apps that change so fast. If we can't support it, we don't include it in stable. So we skipped redmine and gitlab in buster.

We created for packages like gitlab Because gitlab upstream provide support only for 3 months. And stable has at least 1.5 years regular support and then lts So this area is evolving. These apps don't fit into traditional Debian release cycle So we are adapting Debian to include these apps. I hope you got the concept of transitions