2009-09-16 2 views
39

Как бы вы написать build.xml файл, используя ни пользовательского кода, ни внешних зависимостей (например, сценарий оболочки), что:номера Телосложение: major.minor.revision

  • Формирует номер сборки формы основного .minor.revision (например, 01.02.34).
  • Auto-increments ревизия для каждой компиляции исходного кода.
  • Автоматически увеличивает второстепенную версию при каждом выполнении задачи dist (ribution).

Дополнительно:

  • Предоставляет возможность для увеличения основного номера.
  • Предоставляет возможность увеличения младшего номера.
  • Всякий раз, когда основное количество увеличивается, мелкие и номера пересмотра устанавливаются в 0.
  • Всякий раз, когда младший номер увеличивается на единицу, номер ревизии устанавливается в 0.

Бонус:

  • Создает переменную, основанную на номере ревизии git (например, номер версии подрывной версии).

Разъяснение:

  • Автоматический контроль (или фиксации) не требуется.
  • Интеграция с Subversion нежелательна.

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

ответ

53

build_info.properties файл:

build.major.number=00 
build.revision.number=00 
build.minor.number=00 

build.xml файл:

<?xml version="1.0" encoding="UTF-8"?> 
<project name="project" default="current-number"> 

<property file="build_info.properties"/> 
<property name="build.number" value="${build.major.number}.${build.minor.number}.${build.revision.number}"/> 

<target name="current-number"> 
<echo>Current build number:${build.number}</echo> 
</target> 

<target name="compile"> 
    <antcall target="revision"></antcall> 
</target> 

<target name="dist"> 
    <antcall target="minor"></antcall> 
</target> 

<target name="revision"> 
    <propertyfile file="build_info.properties"> 
      <entry key="build.revision.number" type="int" operation="+" value="1" pattern="00"/> 
    </propertyfile> 
</target> 

<target name="minor"> 
    <propertyfile file="build_info.properties"> 
      <entry key="build.minor.number" type="int" operation="+" value="1" pattern="00"/> 
      <entry key="build.revision.number" type="int" value="0" pattern="00"/> 
    </propertyfile> 
</target> 

<target name="major"> 
    <propertyfile file="build_info.properties"> 
      <entry key="build.major.number" type="int" operation="+" value="1" pattern="00"/> 
      <entry key="build.minor.number" type="int" value="0" pattern="00"/> 
      <entry key="build.revision.number" type="int" value="0" pattern="00"/> 
    </propertyfile> 
</target> 

<target name="all"> 
    <propertyfile file="build_info.properties"> 
      <entry key="build.major.number" type="int" operation="+" value="1" pattern="00"/> 
      <entry key="build.minor.number" type="int" operation="+" value="1" pattern="00"/> 
      <entry key="build.revision.number" type="int" operation="+" value="1" pattern="00"/> 
    </propertyfile> 
</target> 

</project> 
+0

Не могли бы вы объяснить, как увеличиваются значения 'major',' minor' и 'revision'? Я понимаю '' задачи, но я не знаю, когда вызываются цели. Это только для Java? Я хотел сделать такие вещи с помощью проекта плагина jQuery (создание с помощью Closure Compiler), возможно ли это? – Wirone

+0

@Wirone Это немного объясняет, хотя я не уверен, что будет «задачей распределения»: http://en.wikipedia.org/wiki/Software_versioning –

+0

Я использовал этот скрипт для муравьев, моя проблема в том, что я экспортирую после этого файл jar. Но номера версий в файле свойств еще не обновляются, когда я создаю банку. Я использую VersionNumber в имени файла моего банка – user2071938

3

Процесс построения

  1. build_info.properties будет создан в процессе сборки в папке проекта Вы могли бы написать всю информацию о вашей сборке в этом файле.
    • Как и номер сборки, основные и младшие номера выпуска, отметки времени и номера ревизии.
  2. Ваш сценарий сборка может изменить эти значения, как никогда ваш хочет
  3. После сборки была преуспевающим совершить файл «build_info.назад свойство в хранилище

Во время развития

После первого создания файла build_info.properties будет помещен в хранилище. Вы можете изменить и зафиксировать любое число (основные, второстепенные, строковые номера) самим собой, когда захотите, или увеличить его автоматически во время сборки, например build.number, в приведенном ниже примере.

svnant Пример

Использование svnant 1.3.0:

<target name="checkout"> 
    <echo>Checking out revision ${param_SubProjectSvnREV} of project: ${param_SubProjectSvnName}</echo> 
    <svn username="${svnant.repository.user}" password="${svnant.repository.passwd}"> 
     <checkout url="${svnant.latest.url}/${param_SubProjectSvnName}/" revision="${param_SubProjectSvnREV}" destPath="${all.projects.dir}/${param_SubProjectDirName}" /> 
     <info target="${all.projects.dir}/${param_SubProjectDirName}" ></info> 
    </svn> 
    <propertyfile file="${all.projects.dir}/${param_SubProjectDirName}/build_info.properties" comment="Modify build numbers in a properties file."> 
     <entry key="build.number" type="int" operation="+" value="1" pattern="00"/><!--increment it here --> 
     <entry key="build.revision" type="string" value="${svn.info.rev}"/> 
     <entry key="build.major.number" default="01"/><!-- can do some logic here to increase the values, or write value from somewhere else--> 
     <entry key="build.minor.number" default="01"/><!-- can do some logic here to increase the values, or write value from somewhere else--> 
    </propertyfile> 
</target> 

<target name="compile" depends="checkout"> 
    <property file="${all.projects.dir}/${param_SubProjectDirName}/build_info.properties" /> 
    <mkdir dir="${release.name}/${param_SubProjectDirName}/${build.major.number}.${build.minor.number}.${build.number}" /> 
    <!-- compile it to the new folder, an so on... --> 
    <!-- after all, if the build wass successfull, commit the file 'build_info.properties' back to repository --> 
</target> 
0

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

<entry key="build.major.number" value="${global.release.major}"></entry> 
<entry key="build.minor.number" value="${global.release.minor}"></entry> 

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

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

<entry key="build.major.number" type="int" operation="+" default="1" pattern="00"/> 
0

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

муравей -Dbuild.version = 1.2.3

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

муравей -Dbuild.version = svnversion .

муравей -Dbuild.version = date +"%Y%m%d%H%D"

муравей -Dbuild.version = $ {} основных. svnversion .. date +"%Y%m%d%H%D"

и т. Д. Вы можете получить довольно всеобъемлющий, если хотите.

Если вы хотите иметь постоянно увеличивающееся число, вы можете сохранить его в файле, а затем передать его во время компиляции. Например, вы можете сделать:

VER = cat build.version VER = $ ((VER + 1)) эхо $ VER> build.version

Наконец, если вы действительно хотите, чтобы это было в сборке. xml, лучше всего иметь отдельную задачу для выполнения опции increment-and-build и форкировать вложенную муравейную сборку с вашей основной целью. Таким образом, вы бы в конечном итоге с

муравей -> муравей -Dbuild.version = 1.2.3.4 -> ...

Другими словами, учитывая ваш build.xml с (текущей) значение по умолчанию «сборки ', затем измените его на' version 'и попросите команду ant' version выполнить вычисление, за которым следует вложенный вызов и сборка.

Реализация рассматривается как упражнение для читателя, а также перевод подхода к платформе, отличной от UNIX.

+0

Имейте в виду, что у Git нет концепции инкрементного номера версии. Изменения Git - это хэши SHA и не являются числовыми (как правило, они представлены в шестнадцатеричном виде, хотя, конечно, они представляют собой номер под обложками). Тем не менее, главное, что это не постоянно увеличивающееся число, а скорее принимает непересекающиеся прыжки (вверх и вниз) по числовому спектру. Кроме того, ограничения, которые вы ставите на требование, являются непоследовательными.Вы не хотите никаких внешних зависимостей, но у вас есть Git и, предположительно, Ant. – AlBlue

+0

У Git есть концепция увеличения чисел. Вы отмечаете (правильно, используя -s или -a), когда у вас есть интересная версия. Вы используете 'описать', чтобы получить уникальный, доступный для человека номер версии из вашего дерева. – Dustin

+0

Dustin, Номер версии, полученный с помощью описания git, не является уникальным во всех распределенных хранилищах; и в любом случае это комбинация тега и количества коммитов в (локальный) репозиторий с тех пор. Такие вещи, как перезарядка или раздавливание, могут привести к одинаковым номерам, но к разному содержимому. – AlBlue

4

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

  • -Dno.increment.minor = истинный
  • -Dno.increment.revision = истинный

Если свойство inc.major был установлен, тогда основное число будет увеличено, а остальные оба значения будут установлены на ноль. Контрольная сумма SHA-1 вычисляется текстовым представлением файла версии.

Кстати: Если бы было разрешено, вы можете создать свой собственный муравей задачу в Java Script, который включен в JDK 6.

Теперь вот муравей файл

<?xml version="1.0" encoding="UTF-8"?> 
<project name="Numbers" default="dist" basedir="."> 

    <property name="version.file" location="${basedir}/version.properties"/> 

    <target name="inc.revision.properties" unless="no.increment.revision"> 
     <propertyfile file="${version.file}"> 
      <entry key="minor.number" default="00" operation="=" pattern="00" type="int"/> 
      <entry key="major.number" default="00" operation="=" pattern="00" type="int"/> 
      <entry key="build.number" default="00" operation="+" pattern="00" type="int"/> 
     </propertyfile> 
    </target> 

    <target name="inc.minor.properties" unless="no.increment.minor"> 
     <propertyfile file="${version.file}"> 
      <entry key="minor.number" default="00" operation="+" pattern="00" type="int"/> 
      <entry key="major.number" default="00" operation="=" pattern="00" type="int"/> 
      <entry key="build.number" value="00" operation="=" type="int"/> 
     </propertyfile> 
    </target> 

    <target name="inc.major" if="inc.major"> 
     <property name="no.increment.minor" value="true" /> 
     <property name="no.increment.revision" value="true" /> 
     <propertyfile file="${version.file}"> 
      <entry key="minor.number" value="00" operation="=" pattern="00" type="int"/> 
      <entry key="major.number" default="00" operation="+" pattern="00" type="int"/> 
      <entry key="build.number" value="00" operation="=" pattern="00" type="int"/> 
     </propertyfile> 
     <load.version.info/> 
    </target> 

    <target name="inc.minor" depends="inc.major,inc.minor.properties"> 
     <property name="no.increment.revision" value="true"/> 
     <load.version.info/> 
    </target> 

    <target name="inc.revision" depends="inc.major,inc.revision.properties"> 
     <load.version.info/> 
    </target> 

    <macrodef name="load.version.info"> 
     <sequential> 
      <property file="${version.file}"/> 
      <checksum file="${version.file}" property="sha1.number" algorithm="SHA" format="CHECKSUM"/> 
      <echo>Version: ${major.number}.${minor.number}.${build.number}</echo> 
      <echo>SHA1: ${sha1.number}</echo> 
     </sequential> 
    </macrodef> 

    <target name="compile" depends="inc.revision" description="Compile Task"/> 

    <target name="dist" depends="inc.minor, compile" description="Dest Task"/> 

</project> 
+0

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

0

Это было Некоторое время назад, так что это из памяти:

Я создаю специальный блок Label CruiseControl.Net, который поместил номер сборки в каждой сборке. Он поддерживал XML-файл со всеми 4 компонентами номера версии и идентифицировал каждый проект по имени (чтобы он мог поддерживать несколько проектов).

Эти четыре значения, которые были сгенерированы, передаются процессу сборки (nAnt, в нашем случае), который должен был настроить все файлы AssemblyInfo.cs, чтобы отобразить правильный номер сборки.

Отредактировано для заметок. Единственным значением, которое автоматически присваивается, является номер сборки. Номера майора/малой версии были указаны в конфигурации проекта CC.Net. Номер сборки перезапущен в 0001 для каждого изменения основного или младшего номера версии (например, если вы перешли от версии 7.1 к версии 7.3, например, сборка 7.1 может быть на этапе сборки 783, но первая сборка 7.3 началась с номера сборки 1, а в следующем 7,1 билд будет построено 784.

Изменение номера версии просто необходимы настройки 1 настройки файла конфигурации CC.Net

0

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

Увеличение несущественным, если микро является 9, и так далее.

 <target name="increaseBuildNumber" depends="increase.micro, increase.minor, increase.major" description="Increase Build Number"/> 

     <target name="increase.micro" if ="microNotEquals9"> 
      <propertyfile file="build.properties"> 
       <entry key="micro.number" default="0" operation="+" pattern="0" type="int"/> 
      </propertyfile> 

    </target> 

    <target name="increase.minor" if = "microEquals9andMinorNotEquals9"> 
      <propertyfile file="build.properties"> 
       <entry key="minor.number" default="0" operation="+" pattern="0" type="int"/> 
       <entry key="micro.number" value="0" operation="=" pattern="0" type="int"/> 
      </propertyfile> 

    </target> 

    <target name="increase.major" if = "microAndMinorEquals9" > 
      <propertyfile file="build.properties"> 
       <entry key="major.number" default="0" operation="+" pattern="0" type="int"/> 
       <entry key="minor.number" value="0" operation="=" pattern="0" type="int"/> 
       <entry key="micro.number" value="0" operation="=" pattern="0" type="int"/> 
      </propertyfile> 


    </target> 

    <condition property="minorEquals9"> 
      <equals arg1="${minor.number}" arg2="9"/> 
    </condition> 

    <condition property="microEquals9andMinorNotEquals9"> 
      <and> 
       <equals arg1="${micro.number}" arg2="9"/> 
       <not><equals arg1="${minor.number}" arg2="9"/></not> 
      </and> 
    </condition> 

    <condition property="microAndMinorEquals9"> 
      <and> 
       <equals arg1="${micro.number}" arg2="9"/> 
       <equals arg1="${minor.number}" arg2="9"/> 
      </and> 
    </condition> 

    <condition property="microNotEquals9"> 
      <not><equals arg1="${micro.number}" arg2="9"/></not> 
    </condition> 

 Смежные вопросы

  • Нет связанных вопросов^_^