Skip to main content

I am building an angular webapplicationAngular web application with a RESTfulRESTful 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'mI'm still not sure whether iI should use two separate semantic versions, one for the angularAngular frontend and one for the javaJava/springSpring backend, or just one semantic version for both.

The reason why i'mI'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: Thethe frontend app might have a malfunctioning button which requires a bug fix. When the current version is 1.0.0 and iI 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 iI 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.

So 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.

Thank you 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?

I am building an angular webapplication 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.

So 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.

Thank you

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?

deleted 1 character in body
Source Link
Maurice
  • 133
  • 7

I am building an angular webapplication 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 version numberssemantic 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.

So 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.

Thank you

I am building an angular webapplication 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 version numbers 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.

So 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.

Thank you

I am building an angular webapplication 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.

So 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.

Thank you

deleted 1 character in body
Source Link
Maurice
  • 133
  • 7

I am building an angular webapplication with a RESTful backend. I plan on using semantic versioning to differentiate between different releases. I've already read a bit about how to implementsimplement 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 version numbers 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.

So 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.

Thank you

I am building an angular webapplication with a RESTful backend. I plan on using semantic versioning to differentiate between different releases. I've already read a bit about how to implements semantic versioning for web applications but i'm 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 version numbers 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.

So 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.

Thank you

I am building an angular webapplication 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 version numbers 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.

So 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.

Thank you

Source Link
Maurice
  • 133
  • 7
Loading