0

Suppose a project that consists of multiple parts

  1. A file format definition
  2. A library to interact with the file format
  3. A CLI utility application that uses the library to perform tasks

I can do non-backwards compatible changes to (3) without breaking (1) or (2).

I can do non-backwards compatible changes to (2) without breaking (1), but (3) would break.

I can do non-backwards compatible changes to (1) without breaking (3), but (2) would break.

Does this mean that these parts must be different project, so they can have different version numbers?

user877329
  • 6,717
  • 8
  • 46
  • 88
  • We had similar requirement, we ended up having a definition xml which decides how upgrade proceeds. Like . You can actually plan out the logic. – user2039152 Jan 31 '21 at 08:55

1 Answers1

0

A version string can refer to a collection of independently versioned API's/packages, a single API, an API and implementation, etc. Basically you have to be cognizant of exactly what it is you are applying a version number to, and what your customers expect. Semantic versioning is all about telling your customers about the risks you think they will take, if they accept an update from you.

From your description, I think you have three things that need to be versioned:

  1. The file format.
  2. The library.
  3. the CLI utility application.

Whether you develop them in one, two or three repos is up to you. It's not uncommon for a file format specification to be developed and versioned independently of any implementations that depend on it. Whether your library and CLI utility belong together or in separate repo's is a matter of your development process logistics and customer expectations. Do you have consumers of the library that don't require your utility?

Whether they reside in one repo, two or three, you should package and version them separately. This implies independent feeds and packaging scripts.

jwdonahue
  • 6,199
  • 2
  • 21
  • 43