1

I am building an Angular web application with a RESTful backend. I plan on using semantic versioning to differentiate between different releases. I've already read a bit about how to implement semantic versioning for web applications but I'm still not sure whether I should use two separate semantic versions, one for the Angular frontend and one for the Java/Spring backend, or just one semantic version for both.

The reason why I'm wondering this is because on the one hand both applications work in tandem and belong to the same coding project. But on the other hand not all changes made to this coding project will involve both the frontend and the backend application. To give an example: the frontend app might have a malfunctioning button which requires a bug fix. When the current version is 1.0.0 and I release a patch for the bug then the new version would become 1.0.1. But this version number change would only make sense for the frontend app.

However semantic versions don't only reflect bug fixes, they can reflect newly added functionality as well. When I add new functionality it always involves making code changes to both the backend and frontend apps. So in such a case using one version number for both applications would make sense.

What approach would be best? Two separate versions for both the backend and frontend or one general version that reflects all changes across the backend and frontend?

Improve this question
3
  • Who is going to use that version information? For what? Semantic versions are important for dependencies, so you can understand what changes are and are not likely to be compatible, but (unless there are other consumers of the API) aren't as useful for a web app.
    – jonrsharpe
    Jan 31, 2022 at 11:45
  • @jonrsharpe it is useful for the developer. The version information will also be part of the name of the jar file of the backend app. If the jar file of the latest version happens to contain a bug and it can't be fixed immediately then a quick fix would be to run a jar file of a previous version of the app. Next to that i plan to use the version information for git tags.
    – Maurice
    Jan 31, 2022 at 11:55
  • 1
    For what it's worth we use Angular SPA with ASP.NET Core backend, and apply the same version to all the projects in the solution using a script in our build pipe-line. Haven't had an issue with it so far.
    – Eternal21
    Feb 7, 2022 at 15:28

2 Answers 2

Reset to default
3

Semantic Versioning is most useful for APIs, not applications. Once you start getting into user facing applications, terms like "incompatible changes" or "backwards compatible" begin to become less clear. When a human is interacting with a user interface, when does a change become incompatible? I think there are ways to define something like Semantic Versioning for these cases, but that is dependent on your context.

So versioning the RESTful API backend using Semantic Versioning makes a lot of sense. This is especially helpful if you decide to open that API to other clients beside your frontend. The versioning information becomes a good communication tool for client developers to understand the impact of the new API on their clients.

Personally, I'd consider up to three version numbers: the backend API, the Angular frontend client, and perhaps the system as a whole. You can use the Semantic Versioning format for all three, but for the frontend and the whole system (if you decide to version that), you would need to define what constitutes a major, minor, or patch change with respect to how users of the interface are impacted.

Ultimately, what you do really depends on who is consuming the versioning information. If your APIs are private, then I'd look at who the stakeholders of your system are. In some situations, your stakeholders may not care that much about versioning or communication via the version numbers. In others, they may care. Consider your versioning system as a communication tool, what you intend to communicate using it, and who you are communicating that information to.

Improve this answer
0

both applications work in tandem and belong to the same coding project

I don't see why you would try to separate them then. Why have versioning between components of the same app?

I'll go further and say: Why have a hard a network boundary between parts of the same system? Is there a real reason?

If it is truly the same project, i.e. can be released together, there is no reason to have any of the above. Just emit the HTML from the backend. No versioned "REST" interfaces necessary. Much easier, faster, maintainable, extendable. Emit JS code too from backend if you want fancy stuff. It will make your project an order of magnitude easier.

If the reason is, that you have 2 teams and you want them to work independently, you're much better off splitting the application vertically and still have no versioned interfaces at all.

Improve this answer
2
  • Though I perfectly agree with this answer, I am not sure if the OP will be happy with it, since it may require a pretty huge change in their way of working. Nevertheless, I can confirm that splitting applications vertically instead of horizontally is most often the more effective approach. (+1)
    – Doc Brown
    Jan 31, 2022 at 14:41
  • @DocBrown is right. If i were to emit HTML from the backend (as happens when you use something like Django framework for example) then it would nog longer be a single page app (SPA). The question is how to use Semantic versioning for SPA applications with a RESTful backend.
    – Maurice
    Jan 31, 2022 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.