Вопрос по version-control, javascript – Должен ли я контролировать версии минимизированных версий моих плагинов jQuery?

10

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

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

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

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

Ваш Ответ

3   ответа
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.

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

Хотя я добавил свой ответ, мне он тоже нравится
Спасибо за это. Поскольку минимизированные версии, # 2, могут быть созданы с помощью сервиса минификаторов, я не буду их фиксировать. Chris Laplante
Я подожду немного, чтобы принять это, чтобы увидеть, есть ли другие ответы, но мне этот очень нравится. Chris Laplante
8

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

У нас были проблемы при добавлении сгенерированных файлов в систему управления версиями (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).

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

Я обновил все свои проекты, чтобы использовать grunt (github.com/cowboy/grunt) построить систему. Намного легче управлять вещами сейчас. Большое спасибо! Chris Laplante
Непрерывная доставка - это фантастическая система. Надо обязательно читать, ИМО.
Я команда из одного человека и никогда раньше не пользовалась системами сборки. Это будет лето, которое я изучу. Я загляну в эту книгу - спасибо! Chris Laplante
4

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.
Я согласен - все, что может быть сгенерировано, не должно быть зарегистрировано, но я не уверен, является ли "ресурс" ресурсом в пункте 1 это правильный термин. По крайней мере, я называю локализованные строки и созданные вручную растровые изображения «ресурсами», но они не генерируются автоматически и, безусловно, должны быть зарегистрированы.
Конечно, есть некоторые совпадения. Хотя я не знаю лучшего термина :) Предложения приветствуются!

Похожие вопросы