Versioning System

General
1

Hey Community!,
I had an improvement idea regarding using CalVer (Calendar Versioning) instead of the old semantic versioning system for the packages.

So I wanted input from you guys on whether it would be a good idea for it.

My points are:

  1. Setting up when to introduce 2.0 from the 1.0 (just an example) is a difficult thing. This also causes a bit of confusion quite a lot of times.
  2. Debugging in CalVer is very easy since the version dates act like a system restore (taking inspiration from windows & Ubuntu systemback), pinpointing where the bug is occurring becomes a charm.
  3. While this isn’t exactly a point but quite a lot of softwares are using this system. Examples include FireFox, Chrome & Ubuntu itself.
2

Welcome to the community, @thefatbandit!

That’s an interesting idea. One thing I like about Ubuntu’s versions is that it is easy to have a notion of how far apart versions are, and when they will EOL.

Unlike semver, it looks like calver is not a well-defined specification though. It doesn’t define when APIs are broken, new features introduced, bugs fixed… All this is well defined in semver and widely understood among programmers. From that link it looks like each project sort of uses their own semantics with calver.

With Gazebo-classic we eventually arrived at a fixed cadence of releases. So even though there are no year numbers explicit on the versions, users know that every major version since Gazebo 7 is spaced by roughly 1 year, with odd versions being LTS. We haven’t reached a fixed cadence for Ignition yet due to its fast development.

That’s to say that we don’t have the common issue of not knowing when a new version is coming. Our release dates are planned in advance and users know when they’re coming.

Another thing to keep in mind is that Ignition has 2 versioning schemes: the named collections (Acropolis, Blueprint, etc) and the versions for the libraries themselves.

Maybe dates could make sense for the collections, like how Ubuntu has a name and a number. But for the individual libraries it could get confusing. While many libraries are bumped for a new collection, others don’t need to be. If we embedded dates into the versions, we may end up with ign-gazebo2025 using ign-common2020 and ign-math2023.

3

@chapulina
Thanks for considering my suggestion & replying to it so promptly,

I agree with you on most points. What I came up with on discussion with my colleagues was somewhat similar to this. So here are my points:

  1. Yes there are no fixed semantics for CalVer till date. But this is due to different development structures & update frequency of different modules in the software.
  2. It was my fault that I didn’t convey the use properly but I too wanted to implement it towards bigger entities like software collections since debugging in libraries is a fairly simple task.
  3. I suggested CalVer mainly from the devs point of view. Thank you for correcting me by showing the users’ POV.

It was nice to have a discussion with you on this. I think I now have an idea of how to get the CalVer system working & will get back to you if I cook up something.

Thanks again for considering the suggestion.