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
Versioning comes in many flavours1 and usually, the solution will convey with the company' business strategy for the app. Whether you "would" or not do version, remains to be seen and decided.
I would not start versioning things if I don't need it. 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.
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 over the code) than over namespaces. Namespaces 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