If you are going to mix v1 and v2 in one current code base you'd need to a have a reason for this. Typically this is because you are going to route old version method calls from your API service to new 'business object methods', this may involve some conversion and such.
If you are going to keep the v1 and v2 paths separate vertically (the code paths aren't sharing anything) you may as well let v1 be served by the old(er) version of your software.
Between v1 and v2 try to bundle API changes so you can offer your clients a document about migrating. API stability is typically appreciated.
Your example on it's own is -not- worth it, it's such a small cosmetic change try to not do those. Or if you do sneak them in while introducing other bigger changes.
While stacking up new interface for your v2 you could offer them early through some sort of extension mechanism, libraries like OpenGl do this.
Try to come up with a deprecation model for your older API surfaces. Supporting all old interfaces till the end of time is going to be hard and very costly.
If at all possible try maintain older version with old distributions of your software. If you can avoid to not mix API generations in one code base do so.
It's very hard to come up with a good interface on the first incarnation of your API surface. Clients may appreciate this, perhaps you can avoid the version management by allowing API instability and breaking changes through a alpha, beta cycle or 0.X releases.