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

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

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

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

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

Ответы на вопрос(3)

что я использую для себя:

If a blob needs to be distributed as part of the source package in order to build it, use it, or test it from within the source tree, it should be under version control. If an asset can be regenerated on demand from versioned sources, do that instead. If you can (GNU) make it, (Ruby) rake it, or just plain fake it, don't commit it to your repository. You can split the difference with versioned symlinks, maintenance scripts, submodules, externals definitions, and so forth, but the results are generally unsatisfactory and error prone. Use them when you have to, and avoid them when you can.

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

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

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

But importantly, все:

tools scripts source code resources third party libraries

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

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

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

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

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

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

Although I believe this is a great idea - and stick to it as best as possible - there are some areas where I am not 100% sure. For example the operating system, the Java JDK, and the Continuous Integration tool (we are using Jenkins).

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

Can this be automatically generated during a build process?

If yes, then it is a resource, not a source file. Do not check it in. If no, then it is a source file. Check it in.

ВАШ ОТВЕТ НА ВОПРОС