Skip to main content
Software Engineering

Return to Answer

added links and highlighted some key elements that seem to have been overlooked by some.
Source Link
Christophe
Christophe
  • 80.6k
  • 11
  • 132
  • 199

The semantic versioning defines versioning rules solely in relation with the API, as it aims to facilitate facilitate the management of dependencies between packages.

Regarding the command line you are in a grey areagrey area. It is a user interface but at the same time it could be usedconsidered as a programming interface (e.g. in scripts). So it's up to you to define how you see it:

  • You may consider that the programme name is part of the APISAPI. Since any shell script would break with your new version, i.e. no backwards compatibility, you would have a majormajor version increment.

  • You may consider that the programme name is not part of the API and that it's only a particular binding. The real API (argumentsparameters and options) is unaltered. In this case, you should consider a minor versionminor increment.

A major version for no new functionality does not seemfeel right. I'd suggest that you offer Offer as part of the installation script or in your API documentation an optional creation of an alias or a copy with the old name to ensure backward compatibilityoptional creation of an alias or a copy with the old name to ensure backward compatibility. You can then go for the minor version with good conscience.

The semantic versioning defines versioning rules solely in relation with the API, as it aims to facilitate the management of dependencies between packages.

Regarding the command line you are in a grey area. It is a user interface but at the same time it could be used as a programming interface (e.g. in scripts). So it's up to you to define how you see it:

  • You may consider that the programme name is part of the APIS. Since any shell script would break with your new version, i.e. no backwards compatibility, you would have a major version increment.

  • You may consider that the programme name is not part of the API and that it's only a particular binding. The real API (arguments and options) is unaltered. In this case, you should consider a minor version increment.

A major version for no new functionality does not seem right. I'd suggest that you offer as part of the installation script or in your API documentation an optional creation of an alias or a copy with the old name to ensure backward compatibility. You can then go for the minor version with good conscience.

The semantic versioning defines versioning rules solely in relation with the API, as it aims to facilitate the management of dependencies between packages.

Regarding the command line you are in a grey area. It is a user interface but at the same time it could be considered as a programming interface (e.g. in scripts). So it's up to you to define how you see it:

  • You may consider that the programme name is part of the API. Since any shell script would break with your new version, i.e. no backwards compatibility, you would have a major version increment.

  • You may consider that the programme name is not part of the API and that it's only a particular binding. The real API (parameters and options) is unaltered. In this case, you should consider a minor increment.

A major version for no new functionality does not feel right. Offer as part of the installation script or in your API documentation an optional creation of an alias or a copy with the old name to ensure backward compatibility. You can then go for the minor version with good conscience.

Source Link
Christophe
Christophe
  • 80.6k
  • 11
  • 132
  • 199

The semantic versioning defines versioning rules solely in relation with the API, as it aims to facilitate the management of dependencies between packages.

Regarding the command line you are in a grey area. It is a user interface but at the same time it could be used as a programming interface (e.g. in scripts). So it's up to you to define how you see it:

  • You may consider that the programme name is part of the APIS. Since any shell script would break with your new version, i.e. no backwards compatibility, you would have a major version increment.

  • You may consider that the programme name is not part of the API and that it's only a particular binding. The real API (arguments and options) is unaltered. In this case, you should consider a minor version increment.

A major version for no new functionality does not seem right. I'd suggest that you offer as part of the installation script or in your API documentation an optional creation of an alias or a copy with the old name to ensure backward compatibility. You can then go for the minor version with good conscience.