Подход к управлению версиями - числа против прилагательных

Question

В основном этот вопрос не имеет определенного ответа, но мне интересно мнение сообщества.Мы собираемся реализовать новую версию моделей данных (мы будем поддерживать существующую на некоторое время).И в настоящее время у нас есть несколько вариантов реализации именования:

1) Используйте некоторый знак реализации (например, User -> gmUser).Сначала мне это не нравится, потому что оно не дает нам решения для будущих изменений.Кроме того, я не хочу связывать имя интерфейса с реализацией

2) Использовать числа для управления версиями (например, User -> v2User / User2, User3 и т. Д.) - этоболее распространенный подход.Но такое название выглядит странно для меня.Кроме того, существует дополнительное предложение переименовать User3 -> User, как только никто не использует оригинальные User

3) Использовать префиксы для версий (например, User -> AwesomeUser,Application -> AwesomeApplication).Под капотом он должен следовать алфавитному порядку, но в целом такое именование просто говорит о том, что User и AwesomeUser - это разные сущности.

Я лично за 3-й вариант.Но мои коллеги говорят, что никто не использует эту опцию.И для этого есть причина.Я знаю, что те, кто использует такие названия, в основном делают это для маркетинга.Но для меня это делает код более читабельным.

Мне интересно мнение сообщества и некоторые профессионалы в отношении лучших практик.

Заранее спасибо

PS, чтобы дать больше контекста - это в основном о запросах GraphQL, поэтому User1 / User2 - разница в настоящее время не в списке полей, а в структуре о способностях

Answer 1

Мы использовали второй подход (User, User2).

1. Понятно, что наименование является временным и, наконец, выживает только одна (конечно, если вы не собираетесь поддерживать обе модели), в то время как User и AwesomeUser могут выглядеть так, что вам нужны обеВерсии модели по разным причинам

2. Алфавитный порядок.Мы хотели, чтобы User и User2 были в одном месте.

Вы также можете переименовать все текущие модели на *Legacy и просто создать User в качестве новой версии.,Таким образом, вам просто нужно удалить все *Legacy после рефакторинга

Answer 2

как насчет реализации управления версиями на уровне файловой структуры

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

позволяет просто изменить путь импорта, но сохранить имя в коде