What decides when a testing/stable update is pushed?

I am kind of assuming that it is just “when the team has time to put something together” but I am curious if there are other factors.

Hello @fasto :wink:

I am not a Member of the Manjaro-Team, but after using the system a long time, I would have a clue about this.

The branches work like this:

  1. On Manjaro unstable you get the packages from ArchLinux stable, mixed with Manjaro’s own packages.
  2. It collects packages for an amount of time and people on the forum vote on how it works and report problems and possible solutions. If there is a problem, is will be addressed. The same does the Manjaro Team, the community part here is an expansion of this work.
  3. If it is stable enough, the current state of all packages will be frozen and pushed to the testing branch. Here it starts again with point 2. If new problems occur it will be addressed and mentioned, if it needs user intervention. Sometimes critical packages will be downgraded and stay on unstable, until a fix come in.
  4. If everything works smooths enough in testing branch after an amount of time, it will be pushed to stable branch. Same process like in point 2 starts again.

That way it has some layers of insurance, that major bugs will not appear on stable branch, but even on stable it needs some user intervention, which are commonly mentioned in #announcements :wink:

Critical packages, like Firefox, Discord, etc. will be fast-tracked.

Hope that makes it a bit clearer.

4 Likes

I do understand the basic breakdown of the branches. What I am more curious about is the specifics, since the updates do not appear to be released on any given schedule. Sometimes a testing update will come out the day after the previous, sometimes a full week. What I’m wondering is what decides that? Is it because someone on Unstable reported a problem with a single package and they hold things back until that package is ready? Are they waiting for a quota of “number of changes in an update”?

This question gets asked a lot and in every distro that I have used. Sooner or later some one will say (and in this case it’s me) it’s released when it ready. A good example is coming up, when KDE 5.27 is released it will be the last of the 5 series and then I expect a longer wait for the first version made with QT6 You can experience this release cycle yourself by joining the testing group. You will see all the problems come up and being fixed and get a better understanding of the procedure.

Manjaro was created due to the fact that our team might need more time to package our overlay packages when there is some update coming from Arch. So we managed to get roughly one stable update out per month. Since the team had grown and technology developed further we are able now to speed up things. There is even a point on which we may fully automate it at some point.

Now the release manager is more or less decides still manually when to do the stable or any other update. On unstable branch multiple staff members sync from Arch as needed. Testing and Stable branch has sometimes some discussions in the team, but more or less the release managers decide in the end when an update seems to be ready.

Most issues will be posted from users on Stable branches anyway. So it sometimes doesn’t really matter when there is an update. The other branches may give us some hints what might regress or get broken, but you will only know when there is feedback in the end.

3 Likes

Really like this part of Manjaro Stable Update (vs Testing and Unstable Update)…

Benefits

  • current enough
  • stable
  • manageble
  • reliable
  • consistent
  • time efficient
  • easier to promote
  • another difference from archlinux

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.