Best Practice - REST API versioning: Where and How to physically store source code

Question

My question is not about best practices for REST API URI design.
I've decided for myself, that i'm going to use the following approach:

https://theserver.com/api/v1/whatsoever

I'm much more curious about how to design the actual sourcecode in advance to easily extend the API with more versions.

Let's assume we've used a classic MVC-Framework for your favorite programming language.
Our API works fine but we want to add & change functionality that is not backwards compatible. We did think about a nice URI design, but didn't think how our code should look in order to work nicely with different API versions. Crap.. What now?

Question: How should the source code for a versionable REST API look like?

Nice to have:

1. Not mixing up the different versions
2. Still best use of DRY
3. Don't reinvent the wheel over again
4. will be extended

Possible answers i can think of:

1. Same project - different Namespaces & Subfolders

Namespace: namespace App\Http\Controllers\v1\Users;
Folder: {root_folder}\app\Http\Controllers\v1\Users\UserLoginController.php

2. Different projects

Point https://theserver.com/api/v1/whatsoever to project 1
and https://theserver.com/api/v2/whatsoever to project 2

Answer 1

Here is my logic: - First of all we need to answer to the question "Why we need versioning?" - If we can extend our API in way it is backward compatible, in that case we don't need versioning (All applications and services are going to use the same API and no changes are needed). - If we can not can not provide backward compatible API in that case we need to introduce next version of our API. This will allow all applications and services to migrate smoothly to new version while to old one is working. After a time period (one year), first version can be obsoleted and stopped.

So based on the answer above I would keep API versions in separate branches in my repository. One codebase, multiple branches for each version. First branch corresponds to v1 which is stable and receives only fixes. No active development here. Second branch corresponds to v2 which has all new features.