Query about release criteria

[manphiz]

Hi, I am one of the maintainers of llama in Debian. I have a question regarding the release criteria of llama. It looks like llama does not closely follow semantic versioning: there is no actual code change since release 0.6.2, and there have been 2 releases (0.6.3 and 1.0.0) since. And the latest version of magit (4.3.8) depends on 1.0.0, which is essentially the same as 0.6.2.

I wonder about the reasoning of the version bumps, as this kind of complicates the package dependency handling and migration in Debian, e.g. magit depends on llama (and transient) and need to wait for those dependencies for migrating to Debian testing, which in turn doesn't have any actual changes.

[tarsius]

Thanks for maintaining the package(s)!

I use "un-dogmatic/traditional/common-sense MAJOR.MINOR.MICRO versioning". When the version looks like 0.*.* then the three levels are compressed into just two fields, which of course leads to a bit of ambiguity. Among other things, 0.*.* means "this is early days, and the likelihood of breaking changes is still increased".

I used to be bad at doing regular releases, and users were unhappy about that, but that changed a year ago, when I switched to "monthly releases". I try to do those release on the first of every month, though sometimes I am a little late, but even then the release happens during the first week of the month (aka "release week"). (There was one exception for Magit (the release happened on the 8th). I also skipped one monthly Forge release, and likely will skip the next.) Of course if there are no changes at all, then I do not create a release [but for 1.0.0 keep on reading].

I might skip a monthly release, especially when it comes to my less popular packages. But even if the package doesn't have many users and if the only change is a typo fix in a docstring, I create a new release two months after the previous release. Now that I actually do monthly(-ish) releases, this is necessary to keep my light OCD in check. (That is why llama-0.6.3 was created.)

I still sometimes create unscheduled releases after fixing a bug, especially if it was a regressions. I usually only bump the MICRO part when doing that, especially when fixing a regression that only appeared in the latest scheduled release a few days earlier and there are no other changes (except maybe cosmetic changes and other bug fixes).

Whether a package is at 0.*.* or >=1.*.* is very significant for my packages. Of the 42 packages I maintain, only four are still at 0.*.*; transient, forge and the virtually unknown tray and sisyphus.

I release 1.0.0 once a package has reached a certain maturity. I was considering releasing Llama numero uno since around 0.4.0, but decided to let it simmer a bit, to see if there were any bugs and/or suggestions -- and indeed after a few more pre-1.0.0 releases with only minor changes, 0.6.2 contained some important changes, that really should be in place before doing 1.0.0.

Since then another four months have passed, without any bug reports or feature requests, and so on the latest release day, I decided that the time for 1.0.0 has come. The fact that there are no changes in v0.6.3..v1.0.0 is not a counter argument -- on the contrary, it is a strong indicator that Llama is indeed finally stable and polished enough for a first stable release. If someone had indeed reported some, even just minor, issue since 0.6.2, then I would not have released 1.0.0 but 0.6.3 or 0.7.0, and I would have waited another few months before releasing 1.0.0.

Even though Llama 1.0.0 is identical to 0.6.3, I bumped the dependency in Magit (and will do so for other dependents, once I create new releases for those). The first stable release of a package is a very significant event and a good time to make a clear cut.

Actually, I tend to bump the specified minimal version of all dependencies to their latest releases when I create a new release, but that is a practice I am currently reconsidering (at least for dependencies I maintain myself). The rational is that if it makes any difference whether version 1.1.0 or 1.1.1 of a dependency is used, then 1.1.1 should have been named 1.2.0 instead. The plan is to stop specifying the full version string m.n.o and use just m.n.

However, I do not intend to decrease dependencies. If a package currently depends on 1.2.1 and the next release of that is 1.2.2, then I will bump to that. But once 1.3.0 of the dependency is released, then I intend to bump to just 1.3, and then I won't bump that until 1.4.0 is released.

[tarsius]

need to wait for those dependencies for migrating to Debian testing, which in turn doesn't have any actual changes.

Some of my packages are tightly coupled.

Ghub, for example, was developed so that it can be used by Forge. I made it available separately, so that other packages could use it as well, but never-the-less Ghub and Forge remain coupled and should always be updated at the same time. (When indicated in the dependency declaration in Forge; of course I do sometimes create minuscule Ghub releases, which don't make a practical difference.)

The next releases of these two packages in particular will come with some breaking changes, and both packages must be updated at the same time. Forge n+1 will absolutely not work with Ghub n, and Forge n will not work with Ghub n+1.

There is no such tight coupling between Magit and Llama, and there no longer is such coupling between Magit and Transient. I.e., usually you can bump just Transient on testing and wait for it to wander through the process, before bumping Magit. Ghub and Forge however must make the journey together.

[manphiz]

Hi Jonas,

Thanks for the thorough explanation! I think it makes more sense to me now, and the new "m.n" over "m.n.o" dependency is a welcoming change that also saves our work. Much appreciated!

And if it's not said enough, thanks for maintaining those packages! Our lives would be much worse without them, and we are very grateful!