Должен ли я контролировать версию мини-версий моих плагинов jQuery?

Скажем, я пишу плагин jQuery и добавляю его в свой репозиторий (Mercurial в моем случае). Это один файл, скажем jquery.plugin.js. Я использую BitBucket для управления этим репозиторием, и одна из его функций - страница "Загрузки". Таким образом, я добавляю jquery.plugin.js в качестве одной из загрузок.

Теперь я хочу сделать доступную мини-версию моего плагина, но я не уверен, что такое лучшая практика. Я знаю, что он должен быть доступен на странице "Загрузки" как jquery.plugin.min.js, но должен ли я также управлять версиями каждый раз, когда я обновляю его, чтобы отразить неминуемую версию?

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

Итак, должен ли я контролировать версию мини файла?

Ответ 1

Нет, вам не нужно сохранять сгенерированные свернутые версии под контролем источника.

У нас были проблемы при добавлении сгенерированных файлов в исходный контроль (TFS) из-за того, как TFS устанавливает локальные файлы только для чтения. Инструменты, которые генерируют файлы как часть процесса сборки, затем имеют проблемы с доступом к записи (это, вероятно, не проблема с другими системами управления версиями).

Но важно, все:

Инструменты
Сценарии
исходный код
Ресурсы
сторонние библиотеки

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

Вы должны иметь возможность проверить определенную версию из исходного элемента управления (по тегу или номеру версии или эквивалент) и воссоздать программное обеспечение точно так же, как и в тот момент. Даже на "свежей" машине.

Строка не должна зависеть от того, что не находится под контролем источника.

Скрипты: build-scripts, будь то файлы ant, make, MSBuild или все, что вы используете, и любые сценарии развертывания, которые, возможно, вам понадобятся для контроля версий - не только на сборке машина.

Инструменты: это означает, что компиляторы, минимизаторы, тестовые среды - все, что вам нужно для ваших скриптов сборки, тестирования и развертывания для работы, должно находиться под контролем источника. Вам нужна точная версия этих инструментов для обновления до момента времени.

Книга 'Непрерывная доставка' научила меня этому уроку - я очень рекомендую его.

Хотя я считаю, что это отличная идея - и придерживайтесь ее как можно лучше - есть некоторые области, где я не уверен на 100%. Например, операционная система, Java JDK и инструмент непрерывной интеграции (мы используем Jenkins).

Вы практикуете непрерывную интеграцию? Это хороший способ проверить, что вы все контролируете. Если вам нужно выполнить ручную установку на машине непрерывной интеграции, прежде чем она сможет создать программное обеспечение, возможно, что-то не так.

Ответ 2

Мое простое правило:

Может ли это быть автоматически создано во время процесса сборки?

Если да, то это ресурс, а не исходный файл. Не проверяйте его.
Если нет, то это исходный файл. Проверьте его.

Ответ 3

Вот разумные правила для репозиториев ™, которые я использую для себя:

Если blob необходимо распространять как часть исходного пакета для его создания, использовать его или тестировать из исходного дерева, он должен находиться под контролем версий.
Если ресурс может быть восстановлен по требованию из версий с версией, сделайте это вместо этого. Если вы можете (GNU) сделать это, (Ruby) обмануть его или просто подделать, не передавать его в ваш репозиторий.
Вы можете разделить разницу с версиями символических ссылок, сценариями обслуживания, подмодулями, определениями внешних и т.д., но результаты, как правило, неудовлетворительны и подвержены ошибкам. Используйте их, когда вам нужно, и избегайте их, когда сможете.

Это определенно ситуация, когда ваш пробег может отличаться, но три разумных правила хорошо работают для меня.