Skip to content

Commit

Permalink
working on release build
Browse files Browse the repository at this point in the history
  • Loading branch information
@bobjacobsen
bobjacobsen committed Oct 20, 2015
1 parent 1eb6eef commit 8b92ac2
Show file tree
Hide file tree
Showing 3 changed files with 107 additions and 55 deletions.
89 changes: 85 additions & 4 deletions build.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1610,6 +1610,88 @@
</target>


<property name="jmri.repository.url" value="https://github.com/bobjacobsen/JMRI.git"/>
<property name="branch-name" value="release-${release}" />

<!-- several steps are involved in creating a new test release
branch from the head of the master branch. This target intends to manage as
many of them as possible -->
<target name="make-test-release-branch"
description="Make a new test release branch in Git from the head of the master branch">

<!-- Create a new branch test release branch from the front of the master
branch in our main repository, and push back to main repo -->

<exec executable="git" failifexecutionfails="true">
<arg value="checkout"/>
<arg value="master"/>
</exec>
<exec executable="git" failifexecutionfails="true">
<arg value="pull"/>
</exec>
<exec executable="git" failifexecutionfails="true">
<arg value="checkout"/>
<arg value="-b"/>
<arg value="${branch-name}"/>
</exec>
<exec executable="git" failifexecutionfails="true">
<arg value="push"/>
<arg value="${jmri.repository.url}"/>
<arg value="${branch-name}"/>
</exec>

<!-- In the newly created release branch, we modify
release.properties to show that we have indeed branched -->
<propertyfile file="release.properties">
<entry key="release.is_branched" type="string" operation="=" value="true"/>
</propertyfile>
<!-- commit and push -->
<exec executable="git" failifexecutionfails="true">
<arg value="commit"/>
<arg value="-m'update release.is_branched for new release'"/>
<arg value="release.properties"/>
</exec>
<!--
<exec executable="git" failifexecutionfails="true">
<arg value="push"/>
<arg value="${jmri.repository.url}"/>
<arg value="${branch-name}"/>
</exec>
-->

<!-- return to master -->
<exec executable="git" failifexecutionfails="true">
<arg value="checkout"/>
<arg value="master"/>
</exec>

<!-- in the master release.properties file, we now increment
the release.build value in order to point to the NEW next
release (the one after we're branching to create) -->
<propertyfile file="release.properties">
<entry key="release.build" type="int" operation="+" value="1"/>
</propertyfile>
<!-- commit and push -->
<exec executable="git" failifexecutionfails="true">
<arg value="commit"/>
<arg value="-m'update release.build to new value post-release'"/>
<arg value="release.properties"/>
</exec>
<!--
<exec executable="git" failifexecutionfails="true">
<arg value="push"/>
<arg value="${jmri.repository.url}"/>
</exec>
-->


<echo message="new release branch ${branch-name}"/>
</target>






<!-- targets to support revision control repository management -->

Expand All @@ -1628,12 +1710,11 @@
<property name="head-dir" value="${tempdir}/HEAD"/>
<property name="branch-dir" value="${tempdir}/BRANCH"/>


<!-- several steps are involved in creating a new test release
branch from trunk/HEAD. This target intends to manage as
branch from the head of the master branch. This target intends to manage as
many of them as possible -->
<target name="make-test-release-branch"
description="Make a new test release branch in SVN, copying the head of the trunk to the new release dir">
<target name="make-test-release-branch-svn"
description="Make a new test release branch in Git from the head of the master branch">

<!-- copy the trunk/HEAD to the new release directory. Since
the trunk's release.properties always points to the NEXT
Expand Down
2 changes: 1 addition & 1 deletion release.properties
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
# these are the numbers for the NEXT release from this branch
release.major=4
release.minor=1
release.build=4
release.build=3

# set this to true if this tree has been branched from the trunk
release.is_branched=false
Expand Down
71 changes: 21 additions & 50 deletions scripts/HOWTO-distribution.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,17 +16,19 @@ So the proposed procedure is:

( ) Jenkins build from that branch. (That’s basically the same Jenkins job, expect for changing to checkout from Github)

( ) As needed, bring in any additional commits requested to branch from master - probably use 'git cherry-pick {commit hash}' to do this. Sometimes also “git merge”, though we’ll have to see exactly how “release.properties” works with this. With SVN, we sometimes created the release a few days in advance to make sure Jenkins was set up, etc, then do final “svn merge” at the appointed time; we might also do this from GitHub. When using 'git merge' would also work we need to be aware of it stamping over 'release.properties' and the correct procedure to revert that.
( ) As needed, bring in any additional commits requested to branch from master - probably use 'git cherry-pick {commit hash}' to do this. Sometimes also “git merge”, though we’ll have to see exactly how “release.properties” works with this. With SVN, we sometimes created the release a few days in advance to make sure Jenkins was set up, etc, then do final “svn merge” at the appointed time; we might also do this from GitHub. When using 'git merge' would also work we need to be aware of it stamping over 'release.properties' and the correct procedure to revert that.

( ) When it’s done, directly publish the files in the usual SF.net way, etc.
( ) After Jenkins has processed the final set of changes, directly publish the files in the usual SF.net way, etc.

( ) (We're also looking at using GitHub releases for distributing the files; this is being done in parallel, so the SF.net file method will co-exist at first.

( ) Turn off the Jenkins job; this is so it doesn't fail after later steps

( ) If need be, merge back changes from the branch to the master as needed. This would be done in a personal fork repo. Might not necessarily need this step if we do changes in 'master' and 'cherry-pick' into branch.

( ) Put a tag titled Release-n.n.n-tag (note initial upper case) on the end of the branch. This starts in a personal fork, then gets pushed back to JMRI/JMRI. This Tag provides a way to get back if somebody accidentally adds to the branch.
( ) Put a tag titled vn.n.n (note initial lower case) on the end of the branch. This starts in a personal fork, then gets pushed back to JMRI/JMRI. This Tag provides a way to get back if somebody accidentally adds to the branch.

The -tag on the end of the name isn't strictly necessary. Git tags and branches are separate name spaces; you can have a tag and branch with the same name. But it can be _very_ confusing when accessing them, because the git command line tools make varying assumptions about the context of their arguments. You end up having to specify whether you’re using a tag or branch most of the time (if there are both with the same name), that’s not how people usually work, and mistakes can happen. From an immediate readability perspective, the '-tag' suffix does easily tell us what it is rather than just the capitalisation or lack thereof. (We will need to clean up the history to suit whichever convention we finally decide on)
(We will need to clean up the history to suit whichever convention we finally decide on)

( ) Delete the branch (to clean up the list of branches in various GUI tools), which can be done in the main JMRI/JMRI repo via the web interface or in a fork & pushed back

Expand All @@ -48,18 +50,15 @@ How best to deal with bringing additional commits into the branch from master -
This is the HOWTO file to make a complete SourceForge downloadable
distribution.

The Ant task that handles the Git operations (see below) invokes Git via direct command line execution. This means that you need to have a working command-line git tool installed and configured. Try "git status" to check.

If you're building locally:
You need to have installed NSIS from http://nsis.sourceforge.net (we use version 2.44)

Either make sure that 'makensis' is in your path, or set nsis.home in your local.properties
file to the root of the nsis installation:
nsis.home=/opt/nsis/nsis-2.46/

To simplify making branches in sourceforge, put your sourceforge userid & password in the local.properties file (this does not get checked in, so your ID remains safe).

sourceforge.userid=zoo
sourceforge.password=IMNOTTELLING

If you're attempting to perform this on MS Windows, refer to the MS Windows notes section at the bottom of this document.

================================================================================
Expand Down Expand Up @@ -126,23 +125,13 @@ release process. They can be skipped occasionally.

to fix it for good. (if you hit a 'has binary mime type`, svn propdel svn:mime-type <filename> )

( ) Confirm that properties, html, etc files have "CVS" properties set. (We don't do this for Git; remove item) They should, but new ones might not.

find java/src -name \*.properties -exec svn propset -q svn:keywords "Date Revision Version Id Author" {} \;
find jython -name \*.py -exec svn propset -q svn:keywords "Date Revision Version Id Author" {} \;
find xml -name \*.xml -exec svn propset -q svn:keywords "Date Revision Version Id Author" {} \;
find help -name \*html -exec svn propset -q svn:keywords "Date Revision Version Id Author" {} \;

You'll get a message for each file, but will only need to commit changes.
svn commit -m"setting SVN keywords" java/src jython xml help

( ) Check for any files with multiple UTF-8 Byte-Order-Marks. This shouldn't usually happen but when it does can be a bit tricky to find. Scan from the root of the repository and fix any files found:

grep -rlI --exclude-dir=.svn $'\xEF\xBB\xBF\xEF\xBB\xBF'

It might be necessary to use a Hex editor to remove the erroneous extra Byte-Order-Marks - a valid UTF-8 file should only have either one 3-byte BOM (EF BB BF) or no BOM at all.

( ) Confirm that all the above changes have been committed back to SVN trunk
( ) Confirm that all the above changes have been committed back to GitHub trunk, and pull back to make sure your repository is at the right point

( ) Run "ant alltest"; make sure they all pass; fix problems and commit back

Expand All @@ -165,30 +154,16 @@ If you fix anything, commit it back.
================================================================================
Second, we build the release branch:

( ) Start the release by copying the current HEAD onto a new SVN "release branch" (This step doesn't seem to work under Cygwin, so needs to be done from the Windows command line) (If needing to make a "branch from a branch", such as nearing the end of the development cycle, this will need to be done manually rather than via ant.)
( ) Start the release by creating a new "release branch" (This step didn't seem to work for SVN under Cygwin, so needed to be done from the Windows command line) (If needing to make a "branch from a branch", such as nearing the end of the development cycle, this will need to be done manually rather than via ant.)

ant make-test-release-branch

(You need to have provided both userid and password in the local.properties file, or it will silently hang; if you don't want to put them in local.properties, you can use this form:

ant -Dsourceforge.userid='you' -Dsourceforge.password='password' make-test-release-branch

instead)

(Alternately, change the svnSetting element in build.xml to:

<svnSetting
id="svn.settings"
javahl="false"
svnkit="false"/>

to have it use your default command line setup; note that this doesn't include user name and password)

(messages like "Missing 'javahl' dependencies on the classpath !" are normal)

This will do (more or less) the following actions:

svn cp -m"start release" ${SVNREPO}/trunk/jmri ${SVNREPO}/branches/jmri/releases/3.9.5
git checkout master
git pull
git branch {branch}
git push {URL} {branch}

<check in an update of the version number of trunk/HEAD>
<check in an update of the version number of the new release>

Expand All @@ -213,8 +188,6 @@ If you don't have this, check out the specific section with

svn co ${SVNREPO}/branches/jmri/releases/3.11.6

Also, don't forget to copy your 'local.properties' file from HEAD

================================================================================
If you're doing the build using the CI engine, configure it to build the new release:

Expand All @@ -230,7 +203,7 @@ If you're doing the build using the CI engine, configure it to build the new rel

Project Name
Description
Subversion Modules Repository URL
Git Modules Repository URL

and click "Save"

Expand All @@ -245,8 +218,6 @@ For local builds, these are the build instructions; CI builds will already be ru

ant -Dnsis.home="" clean packages

(You can get the SVN_REVISION from http://sourceforge.net/p/jmri/code/HEAD/tree/branches/jmri/releases ; don't prefix an 'r')

Ant will do the various builds, construct the distribution directories, and finally construct the Linux, Mac OS X and Windows distribution files in dist/releases/


Expand All @@ -265,7 +236,7 @@ puts them at

================================================================================

If anybody discovers a problem from here on in, they should fix it at the HEAD and have you merge it into the release branch. CI will automatically rebuild, or you'll have to redo a manual build manually.
If anybody discovers a problem from here on in, they should fix it on a Git branch and have you merge it into the release branch. CI will automatically rebuild, or you'll have to redo a manual build manually.

To merge everything to date:

Expand All @@ -285,10 +256,10 @@ Third, we do the release-specific updates.
( ) Create the _next_ release note, so that people will document new (overlapping) changes there.

cd (local web copy)/releasenotes
svn update
svn cp jmri3.11.5.shtml jmri3.11.6.shtml
git pull # to pick up everybody's changes
cp jmri3.11.5.shtml jmri3.11.6.shtml
(edit the new release note accordingly)
svn commit -m"for release"
git commit -m"start new release note" jmri3.11.6.shtml

( ) Change the release note to point to the just-built files (in CI or where you put them), commit, wait (or force) update. Confirm visible on web.

Expand Down Expand Up @@ -341,7 +312,7 @@ Note: the very first time doing this on a new machine, it will be required to ru

( ) Wait until the downloads have propagated to the mirrors; check by trying to download each file

( ) Commit release note file(s) to the web site SVN directory,
( ) Commit release note file(s) to the web site GitHub repository,

( ) Wait for update on JMRI web server

Expand Down

0 comments on commit 8b92ac2

Please sign in to comment.