Skip to content

Latest commit

 

History

History
 
 

release

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
********************************************************************************
The release environment:

Start releases in the morning. If there are problems, you have time to recover.

On conan all release oriented directories and files point through the
symbolic link:

/content/software/idv/current

So we have(in an abbreviated way):
/content/software/idv/data  --> current/data
/content/software/idv/docs  --> current/docs
/content/software/idv/webstart/IDV  --> current/webstart/IDV

Run the test suite (see below) and make sure to update and
check in /ucar/unidata/idv/resources/version.properties.

Before making a release, make sure to update the release notes
in auxdata/docs/userguide/content/ReleaseNotes.html
******************************************************
- Try to add descriptive verbage to each item in the Release Notes.
- The questions (q attribute) should be camel cased (i.e. first letter of each word should be capitalized).
  Words like for, and, a, the don't need to be capitalized.
- If there are other pages in the user guide with more information on the
  change (like a new control page, or something in the preferences), add a link to it from the description.
- The format for menus and sub-menus is Menu->Submenu->Sub-submenu.
  You can use the [ug::menu] macro which will format and bold the menus for you.
  If there are multiple words in a menu, enclose them in braces {}.
  Examples:  [ug::menu Edit Preferences] will show up as Edit->Preferences.
  [ug:menu Edit {Remove All Displays}] will show up as Edit->Remove All Displays
- Release Notes should include items since the last previous major release.
  Updates (e.g. 3.0u1) should include all the notes from the first release of that series (e.g. 3.0)
  up to the current one.
- It's good to update the Release Notes when you add something new so you don't forget about it
  when the official release comes around.
********************************************************

When you are ready to make a release, run:

cd /share/idv/release
svn update build.xml
./buildIdv release

Note that this script has a dependency on install4j license server.
The user running this script must point to the right license server.
As of October 2011, the license server is running on abbott (not zero).
License server configuration information can be found in ~/.install4j4/config.xml.
Therein you will find the license server host. More information on the
install4j license server (including where to download the server) can
be found here:

https://www.unidata.ucar.edu/unidata_only/admin/idv_software_license_info.html

To start the server on abbott the startup script is/etc/rc5.d/S98ejtserver
and the install at /opt/ejtserver.

The above buildIdv command  will run the build, generate the installers, move all
relevant files (installers, docs, webstart) to conan.  The following directories
will be created:

/content/software/idv/<release_dir>
/content/downloads/idv/<release_dir>

where <release_dir> is the version number with underscores (e.g. version 2.8 will be
in <release_dir> 2_8).

Then (see below):

  Update the downloads/idv/toc.xml (see below)

  Expand the javadoc (see below).

  Generate the User Guide and Workshop PDFs (see below)

  Update the index.html page (see below).

  branch the git repository

  change the /content/software/idv/current to point to the new release.

********************************************************************************

Update the downloads toc.xml page

On conan:

cd /content/downloads/idv
edit the toc.xml
  - change the %version% property value
  - change where the current and previous point to

change the current link to point to the new release.
cd /content/downloads/idv
   rm current
   ln -s <current IDV version> current

********************************************************************************

Expand the javadoc

cd /content/software/idv/<release>/docs
jar xvf ~ftp/pub/idv/<release_dir>/idv_javadoc_<version>.jar
cd docs
mv javadoc ..
cd ..
rm -rf META-INF/ docs

********************************************************************************

Generate the PDFs

You  need to build the userguide.pdf and workshop.pdf files.
To do this you need to be on harpo (which has the htmldoc executable)
and run:
ant docs_pdf
from /share/idv/runtime
This will generate the userguide.pdf and workshop.pdf and place them in the
docs directory.

Note that ant may not be on your path. Look for it in

/share/apache-ant/

Look at the ant output and you will see where these PDFs are located.

Once this is done, copy them to conan:

/content/software/idv/<release>/docs/userguide/userguide.pdf
/content/software/idv/<release>/docs/workshop/workshop.pdf

********************************************************************************

Changing the index.html page

cd /content/software/idv/<release_dir>

cp ../<previous_release_dir>/index.html index.html.<release_dir>

edit the index.html.<version> file and update the IDV News and Announcements
section with information about the new release. Also edit the "Posted" date.

cp index.html.<version> index.html

(If you have to redo the release, index.html will get overwritten.  That's why
we make the edits in index.html.<version>)

Open https://www.unidata.ucar.edu/software/idv/<release_dir> in a web browser.
Test all the links to the docs.  Fix any broken links.

********************************************************************************

Tag the git repository:

After the release of a version, you should make a tag in the git repository
in case changes are needed later.  To tag the git repository,
run:

git tag v<version>
git push origin v<version>

See the git history for tag examples.

********************************************************************************

Update the current and stable links:

cd /content/software/idv
rm current
ln -s <current IDV version> current

cd release
rm stable
rm current
ln -s ../<current IDV version> current
ln -s ../<stable IDV version> stable    (or simply point stable to current)

Go to the IDV homepage and make sure it is pointing to the updated directory.  Make
sure all the links on the page work correctly.

********************************************************************************

Send out email to community:

[email protected]
[email protected]
[email protected]

Dear IDV User Community,

IDV XXXX is now available for download <https://www.unidata.ucar.edu/downloads/idv/XXXXX/>.

[Info about the release]

See the release notes <https://www.unidata.ucar.edu/software/idv/docs/userguide/ReleaseNotes.html>
for a complete list of new features.

Best Regards,

The Unidata IDV Team

********************************************************************************

The IDV Testing Suite

The code for IDV testing suite is contained within this git repo:

https://github.com/Unidata/idv-test

The IDV testing suite make use of Docker technology. See here for more
information on running the test suite with Docker:

https://hub.docker.com/r/unidata/idv-test/

Currently, the testing suite runs on a nightly basis on our Azure resources.
Please see here for the results of these tests:

http://unidata-idvtest.cloudapp.net/compare.html

********************************************************************************

Building/configuring the installers

build.xml:

The entire build process is quite Baroque owing to the complexity of the IDV,
and the long history of the project. Currently the nightly build runs from spock
from Yuan's crontab:

5 1 * * * /share/idv/release/newbuildIdv nightly > /share/idv/nightly.log 2>&1
5 2 * * * mailx -s "IDV Build Status" [email protected] [email protected] < /share/idv/nightly.log

Naturally the IDV is built from what is in version control EXCEPT for the
build.xml file in /share/idv/release/build.xml. This file must be manually
maintained and copied over from release/build.xml in the git repository when
there are changes. Make sure to tread lightly here and make any backups before
overwriting anything. Note that /share/idv/release/build.xml contains passwords
that the release/build.xml does not have. It is instructive to simply do a diff
between these files. For the build make sure these two build.xmls stay in sync
except for any passwords. Don't check passwords into version control! See the
section about certificates below:

Installers:

The installers are built automatically by ant using install4j ant tasks which is
located in /share/install4j.  We have a single, multi-platform license which
means that only one copy can run at a time, but on any machine you want even VMs
as long as it is on the Unidata network.

Website for install4j is
http://www.ej-technologies.com/products/install4j/overview.html.  The Unidata
Admin staff has the license information.  The license server runs on abbott as
of October 2011.

The install4j support staff is usually pretty responsive so contact them if you
have trouble: ej-technologies Support <[email protected]>

The configuration file is in git:
/src/ucar/unidata/idv/release/installer/idv.install4j.  This file is used as a
template for the installer and copied to /share/idv/installers during the build
process.  At that point, the version number is filled in.

To make configuration changes, run /share/install4j/bin/install4j and open the
template.  After making changes, test the build and if it works as you expect,
save the changes back to the template.

JRE bundles:

The JREs that are included in the installers need to be updated periodically as
new versions of Java come out. This process has been made much easier for a
variety of reasons. We can generally use the JRE provided by install4j. 

http://resources.ej-technologies.com/install4j/help/doc/index.html#install4j.helptopics.concepts.jreBundles

For Linux, we use Vagrant VMs coupled with install4j for the creation of the
JRE.  The Vagrantfiles are located in release/vagrant. Note you will have to run
those Vagrant VMs on the Unidata network to have access to the install4j license
sever.

The platforms currently supported by the IDV are

- linux
- linux64
- windows
- windows64
- mac os x

On Linux Vagrant VMs, it is a matter of:

- downloading the JRE from oracle.com
- logging into the Vagrant VM of the particular OS
- unpacking the OS specific JRE to a known directory
- running install4j to create a new JRE bundles.  Also, you must run the
install4j bundle wizard on the specific OS (Vagrant machine)for a given JRE
bundle.

Now that you have done the work of obtaining the JREs, for all platforms, to
create a JRE bundle in install4j, start it up and select the Project->Create a
JRE Bundle menu (this menu item is not available on OS X for install4j version 4
so don't tear your hair out looking for it) and step through the process. The
important page is the Select a JRE:

- select the top level of the unpacked JRE
- Input the version of the JRE (e.g. 1.8.0_45)
- For the custom id, use the java 3d version  (e.g., j3d1.5.2)

The resulting JRE bundle will use this to create a name like:

linux-i386-1.6.0_20.5.2.tar.gz

The JRE bundles are automatically stored in /share/install4j/jres (if you are
running install4j from /share/install4j/bin), except on Windows.  It will be
stored in the jres directory of the Windows install4j installation and then has
to be manually copied over to /share/install4j/jres.

Once you have created the JRE bundles, you need to update the install4j template
to point to the new versions.  There are two ways to do this.  The most
fool-proof way is to run install4j and update the Media instances to point to
the new bundles.  The other is just to edit the template.  If you do the latter,
just make sure you change all references.

SSEC uses install4j for McIDAS-V, so you can contact them for help
with the program.  We also share the JRE bundles with them for
platforms that we don't have.

The Unidata admin staff has the information on licenses and passwords
to get in to download new versions.

Java 3D:

Java 3D is being maintained by the open source community. The API is frozen, bug
fixes only (and, yes, they really do fix bugs). The best place to obtain
information on the status of Java 3D is the JogAmp Java 3D forum:
http://forum.jogamp.org/java3d-f3728156.html

Contrary to the past, the Java 3D files are contained in zip files in libsrc
directory. The files are incorporated into the install4j build process so that
they end in the correct place in the IDV distribution. These need to be
periodically updated with a recent JOGL and Java 3D jars. But doing so requires
careful and systematic testing of the IDV. If you find a bug, provide an
isolated test case and report back to the forum.

See here for more information:

https://gouessej.wordpress.com/2012/08/01/java-3d-est-de-retour-java-3d-is-back/

Even though this blog entry is old, it is periodically updated.

********************************************************************************

Certificate Signing

Unfortunately, we live in a much more stringent security environment than in the
past. This means the IDV distributions on OS X, Windows, and Java Webstart must
have certificates otherwise the users will run into various problems including
not being able to run the IDV. Obtaining these certificates can be a pain. You
will have to work with the security group at UCAR-CISL whenever they expire.

The certificates for Windows and OS X are kept in /share/idv/Certicates. Therein
you will find .p12 files. Work with UCAR-CISL security to obtain these
certificate files when they expire. See the General Settings, Code Signing Tab
in install4j for more information of about the signing process. On OS X a
"Developer ID" certificate (and no other kind of certificate) is mandatory.

For Webstart, see the release/build.xml and search for "sign".

For signing passwords, see /share/idv/release/build.xml. Don't store passwords
in version control! 

********************************************************************************

Java 3D Hosting.

As of September 2011, Oracle no longer hosts properly signed Java 3D jars necessary
for Java Web Start.

https://forums.oracle.com/forums/thread.jspa?messageID=9882107

Unidata now host those jars here signed with our own certificate.

https://www.unidata.ucar.edu/software/idv/java3d/java3d-latest.jnlp

Please note that when the certificates expire it will be necessary to resign those
jars.

jarsigner -keystore file:///share/idv/.keystore -storepass XXXXX <jar file> idv

For the password, see the IDV ant build.xml.

Please see here for more information:

https://www.unidata.ucar.edu/unidata_only/admin/idv_software_license_info.html