Return to Answer

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions come in many flavours¹ and usually, the solution conveys with the company' business strategy for the app. Whether you "would" or not version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it. At the moment, you can replace|remove deprecated code, making the source code to be clean and concise. Use the SCM to retrieve old implementations and track changes, don't do it through the source code itself (comments or duplicated components).

Later, if you have to version, consider doing versions of components (classes, libraries, etc) instead of namespaces because backward compatibility is easier to treat with code (via OOP principles, patterns and another programming practices) than with namespaces or directories.²

If you find yourself having to maintain N different versions of the source code and they get different SDLCs, then implement the branch strategy that best meets your needs of maintainability, deployment and delivery. Or fork the code. Whatever route you pick. Take advantage of the SCM capabilities to version the source code.

As for versioning the web API. That's a whole different subject that worth its own question on S.E.

Note: There're alternatives to the well-known versioned URIs, what in my opinion is a huge mistake

^{1: source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies
2: The later should tell about the application, about the business rather than versions and other details of the sort.}

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions come in many flavours¹ and usually, the solution conveys with the company' business strategy for the app. Whether you "would" or not version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it. At the moment, you can replace|remove deprecated code, making the source code to be clean and concise. Use the SCM to retrieve old implementations and track changes, don't do it through the source code itself (comments or duplicated components).

Later, if you have to version, consider doing versions of components (classes, libraries, etc) instead of namespaces because backward compatibility is easier to treat with code (via OOP principles, patterns and another programming practices) than with namespaces or directories.²

If you find yourself maintaining N different versions of the source code and they have different life cycles, then implement the branch strategy that best meets your needs for maintainability, deployment and delivery. Or fork the code. Whatever route you pick.

As for versioning the web API. That's a whole different subject that worth its own question on S.E.

Note: There're alternatives to the well-known versioned URIs, what in my opinion is a huge mistake

^{1: source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies
2: The later should tell about the application, about the business rather than versions and other details of the sort.}

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions comes in many flavours¹ and usually, the solution convey with the company' business strategy for the app. Whether you "would" or not do version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it. At the moment, you can replace / remove deprecated code, what will make the source code to be clean and concise. Use the SCM to retrieve old implementations and track changes, don't do it throught the source code itself (comments or duplicated components).

Later, if you have to do versions, consider versioning components (classes, libs, etc) instead of namespaces because dealing with backward compatibility is fairly easier to do with code (OOP principles, patterns and other good practices will help) than with namespaces. The later should tell about the application, about the business rather than versions and other details of the sort.

If you find yourself having to maintain N different versions of the source code and they get different SDLCs, then implement the branch strategy that best meet your needs of maintainability, deployment and delivery. Or fork the code.

  Whatever route you pick. Take advantage of the SCM to version the source code. Versioning namespaces is not as resourceful as an SCM could be.

As for versioning the web API. That's a whole different subject that worth its own question on S.E. But do it as the need comes.

Spoiler: There're alternatives to the well-known versioned URIs

^{1  : source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies}

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions come in many flavours¹ and usually, the solution conveys with the company' business strategy for the app. Whether you "would" or not version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it. At the moment, you can replace|remove deprecated code, making the source code to be clean and concise. Use the SCM to retrieve old implementations and track changes, don't do it through the source code itself (comments or duplicated components).

Later, if you have to version, consider doing versions of components (classes, libraries, etc) instead of namespaces because backward compatibility is easier to treat with code (via OOP principles, patterns and another programming practices) than with namespaces or directories.²

If you find yourself having to maintain N different versions of the source code and they get different SDLCs, then implement the branch strategy that best meets your needs of maintainability, deployment and delivery. Or fork the code. Whatever route you pick. Take advantage of the SCM capabilities to version the source code.

As for versioning the web API. That's a whole different subject that worth its own question on S.E.

Note: There're alternatives to the well-known versioned URIs, what in my opinion is a huge mistake

^{1: source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies
2: The later should tell about the application, about the business rather than versions and other details of the sort.}

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions comes in many flavours¹ and usually, the solution convey with the company' business strategy for the app. Whether you "would" or not do version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it.

  At the moment, you can replace / remove deprecated code, what will make the code base to be clean and concise. Use the SCM to retrieve old implementations, don't do it throught the source code itself (commented code or duplicated components).

Later, if you have to version the API, consider versioning components (classes, libs, etc) Instead of namespaces because dealing with backward compatibility is fairly easier to deal with over source code (OOP principles, patterns and other good practices will help) than over namespaces. The later should tell about the application, about the business rather than versions and the like.

If you find yourself having to maintain N different versions of the source code and they get different SDLCs, then implement the branch strategy that best meet your needs of maintainability and deployment. Or fork the code.

Whatever route you pick. Take advantage of the SCM to version the source code. Versioning namespaces is not as resourceful as an SCM could be.

As for versioning the web API. That's a whole different subject that worth its own question on S.E. But do it as the need comes.

Spoiler: There're alternatives to the well-known versioned URIs

^{1 : source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies}

well, in my current case, I don't need to keep backwards compatibility, because the system is not yet in production... but in a real-life case, I would have to keep it until all users had updated their apps to the new version

Versions comes in many flavours¹ and usually, the solution convey with the company' business strategy for the app. Whether you "would" or not do version, remains to be seen and decided. Your doubts come from the fact that you are trying to solve a problem that has not yet happened and that makes you see (or not) the so many "flavours" you can pick.

That said, don't version things if you don't need it. At the moment, you can replace / remove deprecated code, what will make the source code to be clean and concise. Use the SCM to retrieve old implementations and track changes, don't do it throught the source code itself (comments or duplicated components).

Later, if you have to do versions, consider versioning components (classes, libs, etc) instead of namespaces because dealing with backward compatibility is fairly easier to do with code (OOP principles, patterns and other good practices will help) than with namespaces. The later should tell about the application, about the business rather than versions and other details of the sort.

If you find yourself having to maintain N different versions of the source code and they get different SDLCs, then implement the branch strategy that best meet your needs of maintainability, deployment and delivery. Or fork the code.

Whatever route you pick. Take advantage of the SCM to version the source code. Versioning namespaces is not as resourceful as an SCM could be.

As for versioning the web API. That's a whole different subject that worth its own question on S.E. But do it as the need comes.

Spoiler: There're alternatives to the well-known versioned URIs

^{1 : source code versioning, app versioning, web API versioning, ... Each of which implementing different strategies}