Skip to content
Permalink
Browse files

for 4.13.5

  • Loading branch information...
bobjacobsen committed Oct 21, 2018
1 parent 1d012a3 commit 36229ecde34ace5f2a38a58ba9ffd347e8bac9a6
Showing with 52 additions and 52 deletions.
  1. +1 −1 pom.xml
  2. +51 −51 scripts/HOWTO-distribution.md
@@ -6,7 +6,7 @@
<name>JMRI</name>
<groupId>org.jmri</groupId>
<artifactId>jmri</artifactId>
<version>4.13.4-SNAPSHOT</version>
<version>4.13.5-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<release.build_user>${user.name}</release.build_user>
@@ -74,11 +74,11 @@ If you're attempting to perform this on MS Windows, refer to the MS Windows note
- Update this note by executing the following line in your JMRI repository directory while you _don't_ have this file open in an editor. There are more details in the update-HOWTO.sh comments; arguments when you run it should be last release, this release you're making, the next release; you may need to update what's below:
```
./scripts/update-HOWTO.sh 4.13.3 4.13.4 4.13.5
./scripts/update-HOWTO.sh 4.13.4 4.13.5 4.13.5
```
(and then manually update the end of that line above to be this version being made today, next version to be made later, one after that; i.e. when starting to do *.4, the arguments after you edit it here are *.4 *.5 *.6)
- To check the script ran OK, the following should be the release you're doing now: 4.13.3
- To check the script ran OK, the following should be the release you're doing now: 4.13.4
- Go to the master branch on your local repository. Pull back from the main JMRI/JMRI repository to make sure you're up to date.
@@ -167,7 +167,7 @@ We roll some general code maintenance items into the release process.
- Commit the current copy of these notes, the push directly back to master on GitHub.

```
git commit -m"for 4.13.3" scripts/HOWTO-distribution.md
git commit -m"for 4.13.4" scripts/HOWTO-distribution.md
git push github
```

@@ -184,13 +184,13 @@ git push github
```
cd (local web copy)/releasenotes
git pull
cp jmri4.13.3.shtml jmri4.13.4.shtml
cp jmri4.13.4.shtml jmri4.13.5.shtml
(edit the new release note accordingly)
change numbers throughout
move new warnings to old
remove old-version change notes
git add jmri4.13.4.shtml
git commit -m"start new 4.13.4 release note" jmri4.13.4.shtml
git add jmri4.13.5.shtml
git commit -m"start new 4.13.5 release note" jmri4.13.5.shtml
git push github
cd (local JMRI copy)
```
@@ -216,39 +216,39 @@ where the date at the end should be the date (and optionally time) of the last r

- (MANUAL STEP FOR NOW) Update the <version> element in pom.xml to say the next release:
```
<version>4.13.4-SNAPSHOT</version>
<version>4.13.5-SNAPSHOT</version>
```
Commit, and push back directly to master (this should be the only change, and has to be before the next step)
```
git commit -m"for next release 4.13.4" pom.xml
git commit -m"for next release 4.13.5" pom.xml
git push github
```


- Put the following comment in the release GitHub item saying the branch exists, and all future changes should be documented in the new release note: (NOT FOR THE LAST TEST RELEASE FROM MASTER BEFORE A PRODUCTION RELEASE, see just below)

```
The release-4.13.3 branch has been created.
The release-4.13.4 branch has been created.
From now on, please document your changes in the [jmri4.13.4.shtml](https://github.com/JMRI/website/blob/master/releasenotes/jmri4.13.4.shtml) release note file.
From now on, please document your changes in the [jmri4.13.5.shtml](https://github.com/JMRI/website/blob/master/releasenotes/jmri4.13.5.shtml) release note file.
Maintainers, please set the 4.13.4 milestone on pulls from now on, as that will be the next test release from the HEAD of the master branch.
Maintainers, please set the 4.13.5 milestone on pulls from now on, as that will be the next test release from the HEAD of the master branch.
Jenkins will be creating files shortly at the [CI server](http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.3/)
Jenkins will be creating files shortly at the [CI server](http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.4/)
```

FOR THE LAST TEST RELEASE FROM MASTER BEFORE A PRODUCTION RELEASE:

```
The release-4.13.3 branch has been created.
The release-4.13.4 branch has been created.
From now on, please document your changes in the [jmri4.13.4.shtml](https://github.com/JMRI/website/blob/master/releasenotes/jmri4.13.4.shtml) release note file.
From now on, please document your changes in the [jmri4.13.5.shtml](https://github.com/JMRI/website/blob/master/releasenotes/jmri4.13.5.shtml) release note file.
Maintainers, please set the 4.13.4 milestone on pulls from now on, as that will be the next test release from the HEAD of the master branch.
Maintainers, please set the 4.13.5 milestone on pulls from now on, as that will be the next test release from the HEAD of the master branch.
Jenkins will be creating files shortly at the [CI server](http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.3/)
Jenkins will be creating files shortly at the [CI server](http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.4/)
If you're developing any additional (post-4.13.3) changes that you want in the JMRI 4.14 production release, please start from this branch, i.e. do `git checkout -b release-4.13.3` to start your work.
If you're developing any additional (post-4.13.4) changes that you want in the JMRI 4.14 production release, please start from this branch, i.e. do `git checkout -b release-4.13.4` to start your work.
```

================================================================================
@@ -267,15 +267,15 @@ If you're developing any additional (post-4.13.3) changes that you want in the J
Project Name
Description
Git Modules: Branch
Clone (Advanced) refspec should be +refs/heads/master:refs/remotes/origin/release-4.13.3
Clone (Advanced) refspec should be +refs/heads/master:refs/remotes/origin/release-4.13.4

- Check under Source Code Management, Additional Behaviours, Advanced Clone Behaviours "Honor refspec" and "Shallow Clone" are checked, Shallow Clone Depth is 1, and time out is 20.

- Click "Save". If needed, click "Enable".

- The build will start shortly (or click "Build Now"). Wait for it to complete.

- On your local machine, open jvisualvm. Start "ant alltest" and attach jvisualvm to it. When it's done, put a screen-shot of the four monitor graphs into the "Create Test Release 4.13.3" Github issue so that historical resource usage info is available.
- On your local machine, open jvisualvm. Start "ant alltest" and attach jvisualvm to it. When it's done, put a screen-shot of the four monitor graphs into the "Create Test Release 4.13.4" Github issue so that historical resource usage info is available.

================================================================================
## Put Files Out For Checking
@@ -285,11 +285,11 @@ If you're developing any additional (post-4.13.3) changes that you want in the J
- Announce the file set via email to jmri-developers@lists.sf.net with a subject line

```
"First 4.13.3 files available":
"First 4.13.4 files available":
First JMRI 4.13.3 files are available in the usual way at:
First JMRI 4.13.4 files are available in the usual way at:
http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.3
http://builds.jmri.org/jenkins/job/TestReleases/job/4.13.4
Feedback appreciated. I would like to release this later today or tomorrow morning if the files are OK.
```
@@ -301,23 +301,23 @@ Feedback appreciated. I would like to release this later today or tomorrow morni

If anybody wants to add a change from here on in, they should

- Ideally, start the work on either the release-4.13.3 branch (if working after that was started) or on a branch-from-master that's _before_ the release-4.13.3 branch was created. That way, the change can be cleanly included in the release branch, and also directly onto master.
- Ideally, start the work on either the release-4.13.4 branch (if working after that was started) or on a branch-from-master that's _before_ the release-4.13.4 branch was created. That way, the change can be cleanly included in the release branch, and also directly onto master.

- Commit their changes to that branch, and push as needed to get it to their GitHub fork.

- On the GitHub web site, make _two_ pull requests:

- One to master, as usual

- One to the release branch e.g. "release-4.13.3". The comment on this PR should explain why this should be included instead of waiting for the next release.
- One to the release branch e.g. "release-4.13.4". The comment on this PR should explain why this should be included instead of waiting for the next release.

Merging the PR to the master makes those changes available on further developments forever; the one on the release, if accepted, includes the change and kicks off new runs of the various CI and build jobs.

Note: The GitHub automated CI tests do their build after doing a (temporary) merge with the target branch. If the release branch and master have diverged enough that a single set of changes can't be used with both, a more complicated procedure than above might be needed. In that case, try a PR onto the release branch of the needed change, and then pull the release branch back onto the master branch before fixing conflicts.

If somebody has merged their change into master (or it's branched from master later than the release tag), you have two choices:

- Merge master into the release-4.13.3 branch. This will bring _everything_ that's been merged in, so remember to update the version markers on those PRs. Effectively, you've just started the release process later. Note that the `release.properties` file will have the wrong minor number in it: You'll have to edit and commit that to get the right number in the release.
- Merge master into the release-4.13.4 branch. This will bring _everything_ that's been merged in, so remember to update the version markers on those PRs. Effectively, you've just started the release process later. Note that the `release.properties` file will have the wrong minor number in it: You'll have to edit and commit that to get the right number in the release.

- `git cherrypick` just the changes you want. *This is not the recommended approach, as it is error-prone; we've had to withdraw releases in the past due to this.* Read the documentation on that command carefully and double check your work. If possible, check the contents of the release branch on the GitHub web site to make sure only the changes you wanted were included.

@@ -329,26 +329,26 @@ The following will take several minutes, so be patient:
```
ant clean compile
cd target
rm -f properties.4.13.3.zip
rm -f properties.4.13.4.zip
foreach x ( `find classes -name \*.properties` )
printf '%s\n' 0a '# from tag v4.13.3' . x | ex $x
printf '%s\n' 0a '# from tag v4.13.4' . x | ex $x
end
find classes -name \*.properties | zip -@ properties.4.13.3.zip
find classes -name \*.properties | zip -@ properties.4.13.4.zip
cd ..
mkdir release
mv target/properties.4.13.3.zip release/
mv target/properties.4.13.4.zip release/
```

Then decide what to do with the properties.4.13.3.zip file. Tentatively, we're just attaching the properties.4.13.3.zip file to the release without further mention.
Then decide what to do with the properties.4.13.4.zip file. Tentatively, we're just attaching the properties.4.13.4.zip file to the release without further mention.

====================================================================================
## Format file-release information

Run a script to download the created files, create checksums and create text for release notes, etc
```
./scripts/releasesummary 4.13.3
./scripts/releasesummary 4.13.4
```

====================================================================================
@@ -369,23 +369,23 @@ Note: Once a GitHub Release is created it is *not* possible to change it to refe

- Fill out form:

- "tag version field" gets v4.13.3 (e.g. leading lower-case "v")
- @ branch: select the release-4.13.3 release branch
- "tag version field" gets v4.13.4 (e.g. leading lower-case "v")
- @ branch: select the release-4.13.4 release branch
```
"Release title" field gets "Test/Prod Release 4.13.3"
"Release title" field gets "Test/Prod Release 4.13.4"
```
- Description should contain (the releasesummary script above proposed this!):

```
[Release notes](http://jmri.org/releasenotes/jmri4.13.3.shtml)
[Release notes](http://jmri.org/releasenotes/jmri4.13.4.shtml)
Checksums:
File | SHA256 checksum
---|---
[JMRI.4.13.3+R9e5390b.dmg](https://github.com/JMRI/JMRI/releases/download/v4.13.3/JMRI.4.13.3+R9e5390b.dmg) | 577b4df863b0b5e8f3ba6a0478b74292fec958baa71a9baa3fab8130422732c7
[JMRI.4.13.3+R9e5390b.exe](https://github.com/JMRI/JMRI/releases/download/v4.13.3/JMRI.4.13.3+R9e5390b.exe) | eea78f773154ebd318b336bfccddbd9b3803b126621c039ba2fed002d752361b
[JMRI.4.13.3+R9e5390b.tgz](https://github.com/JMRI/JMRI/releases/download/v4.13.3/JMRI.4.13.3+R9e5390b.tgz) | af3d2cba9938feb311dbbe69c3cf6990501360643331f66ba037df30c632cb23
[JMRI.4.13.4+R9e5390b.dmg](https://github.com/JMRI/JMRI/releases/download/v4.13.4/JMRI.4.13.4+R9e5390b.dmg) | 577b4df863b0b5e8f3ba6a0478b74292fec958baa71a9baa3fab8130422732c7
[JMRI.4.13.4+R9e5390b.exe](https://github.com/JMRI/JMRI/releases/download/v4.13.4/JMRI.4.13.4+R9e5390b.exe) | eea78f773154ebd318b336bfccddbd9b3803b126621c039ba2fed002d752361b
[JMRI.4.13.4+R9e5390b.tgz](https://github.com/JMRI/JMRI/releases/download/v4.13.4/JMRI.4.13.4+R9e5390b.tgz) | af3d2cba9938feb311dbbe69c3cf6990501360643331f66ba037df30c632cb23
```

@@ -411,7 +411,7 @@ git fetch
git checkout master
git pull
git checkout -b temp-master
git merge origin/release-4.13.3
git merge origin/release-4.13.4
```

Note that you're testing the merge of the release branch back onto master. This should report "Already up-to-date.", i.e. no changes, with the possible exception of some auto-generated files:
@@ -433,12 +433,12 @@ If there are any changes in other files, do both of:
====================================================================================
## Update GitHub Status items

- Create the [next GitHub Issue](https://github.com/JMRI/JMRI/issues) to hold discussion with conventional title "Create Test Release 4.13.4". Add the next release milestone (created above) to it. Typical text (get the date from the [milestone page](https://github.com/JMRI/JMRI/milestones)); for later releases in the series copy specific text from the milestone page:
- Create the [next GitHub Issue](https://github.com/JMRI/JMRI/issues) to hold discussion with conventional title "Create Test Release 4.13.5". Add the next release milestone (created above) to it. Typical text (get the date from the [milestone page](https://github.com/JMRI/JMRI/milestones)); for later releases in the series copy specific text from the milestone page:
```
This is the next release in the 4.14 cycle. It's intended to be released around July 12 from HEAD of master.
```

- Confirm that the tag for the current release (v4.13.3 for release 4.13.3) is in place via the [tags page](https://github.com/JMRI/JMRI/tags), then manually delete the current release branch (release-4.13.3) via the [GitHub branches page](https://github.com/JMRI/JMRI/branches).
- Confirm that the tag for the current release (v4.13.4 for release 4.13.4) is in place via the [tags page](https://github.com/JMRI/JMRI/tags), then manually delete the current release branch (release-4.13.4) via the [GitHub branches page](https://github.com/JMRI/JMRI/branches).

- Go to the GitHub PR and Issues [labels list](https://github.com/JMRI/JMRI/labels) and remove any "afterNextTestRelease" (and "afterNextProductionRelease" if appropriate) labels from done items

@@ -480,11 +480,11 @@ git push github

- Mail announcement to jmriusers@groups.io

Subject is "Test version 4.13.3 of JMRI/DecoderPro is available for download" or "JMRI 4.12 is available for download"
Subject is "Test version 4.13.4 of JMRI/DecoderPro is available for download" or "JMRI 4.12 is available for download"

Content:

Test version 4.13.3 of JMRI/DecoderPro is available for download.
Test version 4.13.4 of JMRI/DecoderPro is available for download.

This is the next in a series of test releases that will culminate in a production release, hopefully in December 2018.

@@ -496,18 +496,18 @@ If you are currently using JMRI 4.9.6 or earlier, we strongly recommend that you

If you use JMRI on Linux or Mac and are updating from JMRI 4.7.3 or earlier, there’s a necessary migration step. (Not needed on Windows) Please see the JMRI 4.12 release note for details: <http://jmri.org/releasenotes/jmri4.12.shtml#migration>

For more information on the issues, new features and bug fixes in 4.13.3 please see the release note:
<http://jmri.org/releasenotes/jmri4.13.3.shtml>
For more information on the issues, new features and bug fixes in 4.13.4 please see the release note:
<http://jmri.org/releasenotes/jmri4.13.4.shtml>

Note that JMRI is made available under the GNU General Public License. For more information, please see our copyright and licensing page.
<http://jmri.org/Copyright.html>

The download links, along with lots of other information which we hope you'll read, can be found on the release note page:
<http://jmri.org/releasenotes/jmri4.13.3.shtml>
<http://jmri.org/releasenotes/jmri4.13.4.shtml>

- Close the [current release GitHub Issue](https://github.com/JMRI/JMRI/issues) with a note saying that
```
JMRI 4.13.3 has been released. Files are available in the GitHub release section.
JMRI 4.13.4 has been released. Files are available in the GitHub release section.
```

- Wait a day for complaints
@@ -557,7 +557,7 @@ If you're building locally:
- Get the release in your local work directory

```
git checkout release-4.13.3
git checkout release-4.13.4
```

- edit release.properties to say release.official=true (last line)
@@ -688,9 +688,9 @@ Possibilities for automating GitHub release creation:
Alternatively, if you have shell access to the Jenkins server, you perhaps can upload directly from there, once the initial draft release has been created (this hasn't been tested):

```
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.3 -n "JMRI.4.13.3+Rd144052.dmg" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.13.1/workspace/dist/release/JMRI.4.13.1+Rd144052.dmg
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.3 -n "JMRI.4.13.3+Rd144052.exe" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.7.5/workspace/dist/release/JMRI.4.13.3+Rd144052.exe
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.1 -n "JMRI.4.13.3+Rd144052.tgz" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.7.5/workspace/dist/release/JMRI.4.13.3+Rd144052.tgz
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.4 -n "JMRI.4.13.4+Rd144052.dmg" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.13.1/workspace/dist/release/JMRI.4.13.1+Rd144052.dmg
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.4 -n "JMRI.4.13.4+Rd144052.exe" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.7.5/workspace/dist/release/JMRI.4.13.4+Rd144052.exe
github-release upload -s {github_secret} -u JMRI -r JMRI -t v4.13.1 -n "JMRI.4.13.4+Rd144052.tgz" -f /var/lib/jenkins/jobs/TestReleases/jobs/4.7.5/workspace/dist/release/JMRI.4.13.4+Rd144052.tgz
```

(It might be possible to automate this in Ant, see http://stackoverflow.com/questions/24585609/upload-build-artifact-to-github-as-release-in-jenkins )

0 comments on commit 36229ec

Please sign in to comment.
You can’t perform that action at this time.