Versioning approach - Numbers vs Adjectives

user_3400830 0
Viewed 445

Mostly this question has no certain answer, but I wonder the opinion of the community. We're going to implement a new version of data models (we're going to support existing one for a while). And currently, we have a few options to implement naming:

1) Use some implementation sign (like User -> gmUser). I don't like it first because it doesn't give us a solution for future changes. Plus I don't want to link interface name to an implementation

2) Use numbers for versioning (like User -> v2User / User2 , User3 and so on) - this is more widely spread approach. But such naming looks strange for me. Plus there is a sub-proposal to rename User3 -> User as soon as no one uses original User

3) Use prefixes for versions (like User -> AwesomeUser, Application -> AwesomeApplication). Under the hood, it supposed to follow an alphabetic order, but in general, such naming just says that User and AwesomeUser are different entities.

I'm personally for the 3rd option. But my counterparts say that no one uses that option. And there is a reason for it. I know that those who use such naming mostly do it for marketing. But for me, it makes the code more readable.

I wonder about community opinions and some profs for best practices.

Thanks in advance

P.S. to give more context - it's about GraphQL Queries mostly, so User1 / User2 - difference currently not in the list of fields, while in structure about abilities

naming-conventions design-patterns naming
2 Answers

what about to implement versioning on file structure level

/models
  /ver1
    /User.js
  /ver2
    /User.js

it allows just to change import path but save naming in code

user_100938130

We used second approach (User, User2).

  1. It's clear that naming is temporary and finally only one survives (Of course if you are not going to support both models) while User and AwesomeUser may look like you need both versions of the model for different reasons

  2. Alphabetic order. We wanted User and User2 to be in the same place.

You also can rename all current models now to *Legacy and just create User as a new version. This way you just need to remove all *Legacy after refactoring

user_4380840
Related