Как сохранить ревизию / сборку компонента в версии? - PullRequest
2 голосов
/ 07 октября 2011

Прочитав много статей / вопросов / ответов / книг / книг, я начинаю думать что [MAJOR]. [MINOR]. [REV] является наиболее полезной схемой управления версиями для описать совместимость между версией проекта (схема управления версиями для разработчика, а не для маркетинга).

ОСНОВНЫЕ изменения несовместимы и требуют изменения имя проекта, путь к файлам, GUID и т. д.

Незначительные изменения обратно совместимы. Отметить введение нового особенности.

REV для безопасности / исправления ошибок. Обратная и прямая совместимость.

На моей работе многие проекты зависят от внутренних библиотек, которые хранятся на сервере релизов (FTP). У них есть разные версии, например:

  1.0.0
  1.1.0
  1.1.1

Путь к зависимым библиотекам, включая компонент версии и жесткий закодированы в скриптах сборки для автоматической загрузки в lib dir.

ВОПРОС: Является ли обычной практикой указание пути к библиотекам Сценарий сборки для разработки дома?

ВОПРОС: Это лучше: включите номер версии в название библиотеки или не? Какой компонент включить? Например:

  libfoo-1.so
  libfoo-1.2.jar
  libfoo-2.3.14.dll

Если вы включите только [MAJOR] , вы можете встроить имя библиотеки в источники и с изменениями версии вам не нужно изменять какой-либо код. Как библиотека имеет фиксированное имя, вы всегда можете спросить версию библиотеки на время выполнения (путем вызова соответствующей функции).

Если вы включите [MAJOR]. [MINOR] компонент каждые незначительные изменения требуется обновить все затронутые проекты (вызовы LoadLibrary, CLASSPATH env var). И вы не можете проверить версию во время выполнения, как Стандартный механизм поиска библиотеки во время выполнения обычно делает не разрешать загрузку по имени с подстановочным знаком (например, "libbar-2. *").

Я думаю, что включать [REV] не было необходимости. Вам нужно только предоставить этот компонент для отчетов об ошибках.

ВОПРОС: Я планирую реализовать такую ​​схему: выпуски пакетов в путь, как:

  /srv/projs/foo/1.2.2

и создал символическую ссылку на

  /srv/projs/foo/1.2

из предыдущего пути. Таким образом, каждый зависимый проект не должен делать любые шаги, чтобы получить последнюю библиотеку. Кто-нибудь использует такую ​​схему?

1 Ответ

2 голосов
/ 09 октября 2011

Если вы все еще не используете (любой) SCM, вы находитесь на неверном пути.Если вы не используете компоновщик, который может быть интегрирован с использованным SCM - вы снова на неверном пути

постоянные имена файлов (без * любые номера версий в нем)Самый простой способ поддержки исходных текстов (вы ничего не должны изменять внутри сборки)

...