Search code examples
version-controlpackageversionpackage-management

is it a good thing to fix older sub-versions of a package?

Issue

I have a package with the following versions:

1.0.0
1.1.0
1.2.0~1
1.3.0~3

There are a few small errors that I fixed on the most recent version (1.3.3).
The issue is, these errors persisted from all the way in version 1.0.0 ...

Question

What is the code of conduct for this scenario (if there is any)?

  1. fix all the previous sub-versions (new v/1.0.1)
  2. ignore previous versions and only fix 1.3.3
  3. mark older versions as deprecated (1.0 ~ 1.2)

I scrolled through https://semver.org/ but didn't find anything.

Solution

  • This is less a question of semantic versioning and more of supporting older versions. Some projects maintain stable versions. For example, a project may provide security updates for v1, security and bugfix updates for v2, and new features for v3. Other projects do not, and that's a matter of resources and priorities for the project.

    If your software is very popular and likely to be distributed by Linux distributions or other large distributors, it is often nice to provide stable branches because it means that there is substantially less work on distributors to backport security and bug fixes, since not everyone wants to upgrade to a new version right away. However, you are under no obligation to do so if you don't want to: the matter is completely up to you.