CODEWITHSUNDEEP
semantic-versioning
mridula
mridula

Reputation: 3281

Semantic versioning - major version for a traditional web application

I have a Rails app which is a traditional web application (HTTP requests are processed and HTML pages are rendered). As of now, it does not have an APIs that are exposed to other apps.

I want to use semantic versioning for versioning the application. Currently it is at '0.0.0'.

Quoting from the documentation:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

From what I understand, because there are no applications dependent on mine, the major version will never change. Only the minor and patch versions will change, the major version will always remain 0.

I want to know if my understanding is correct. Is there any scenario in which my major version will change?

Upvotes: 3

Views: 2216

Answers (2)

Shafiq Jetha
Shafiq Jetha

Reputation: 1574

One way you could think about this is to think about the user's flow through the application as the basis for versioning. If a breaking change happens (i.e. the user's flow is changed in a way that makes the old route impossible) then it could be considered breaking. If you're adding new functionality that hasn't existed before (i.e. the user has access to a new feature or sees something new on the website that they can interact with) then that could be considered a minor version increase. If you're deploying minor fixes to things like text, then that could be considered a patch-level change.

The problem with this approach, though, is that you need to understand a user's workflow through the application to be able to correctly increment the major version, and as software developers we're still pretty terrible at doing that properly.

Ref: https://christianlydemann.com/versioning-your-angular-app-automatically-with-standard-version

Upvotes: 2

Joni
Joni

Reputation: 111369

Since you're not developing and releasing software package, semantic versioning is not directly applicable. It sounds like a single "release" number could be enough for your use case, since what you need is track when a code change will be in test and in prod. Assuming code must go through test before going to prod, you would update the number whenever you update the test environment with code from the development branch. This way, at a given moment development would have release N, test would have N-1, and prod N-2.

API versioning is a different problem, independent of release numbering. In my experience API users only care about breaking changes, so those need to be versioned. Also, since users are slow to update their apps you must be prepared to keep old versions around indefinitely.

Upvotes: 2

Related Questions