Source Release for BES: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
mNo edit summary
mNo edit summary
Line 3: Line 3:
Here's how to make a source release:
Here's how to make a source release:


#First, make sure that the source code you're using is on the trunk, up-to-date (''svn up'') and that the software passes its tests and no outstanding tickets remain for the release milestone.
# First, make sure that the source code you're using is up-to-date and that the software passes its tests and no outstanding tickets remain for the release milestone. Make sure '''make check -j9''' and '''make distcheck -j9''' work. Checking '''make rpm''' is useful for a beta release because it will find problems that can slow the process once the final edits are done and the RPMs are being built. Note that for the BES, or any software that requires parameters passed to configure, use '''DISTCHECK_CONFIGURE_FLAGS=...''' when you run ''make''. A typical distcheck for the BES is ''make distcheck -j9 DISTCHECK_CONFIGURE_FLAGS=--with-dependencies=$prefix/deps'' and yes, it's a pain to type... For tests, using '''TESTSUITEFLAGS=-j9''' will speed up the autconf/autotest tests if the version of autoconf supports parallel testing.
#Update the text documentation files and version numbers in the configuration files:
# Update the text documentation files and version numbers in the configuration files:
#*Update the '''ChangeLog''' file using the script ''update_cl.sh'' which can be found in the ''svn-tools'' project. (e.g., ~/svn-tools/update_cl.sh ChangeLog). If you're making the first ChangeLog entries, then you'll need to create the ChangeLog file first. Here's a key tip: When you're making the commit log entries, always include the file name(s) of the affected files in your entry. Then to write the NEWS file, just read over the new ChangeLog entries and summarize. In the old days of CVS, the logs automatically included the names of the changed files, but subversion doesn't do that. A little discipline with those log entries will go a long way toward streamlining the release process!
#* Update the '''ChangeLog''' file using the script ''gitlog-to-changelog'' which can be found with Google. If you're making the first ChangeLog entries, then you'll need to create the ChangeLog file first. Here's a key tip: When you're making the commit log entries, use line breaks so ChangeLog will be readable. That is, use lines < 80 characters long.
#*Make sure that the version number is set in the '''configure.ac''' and '''*.spec''' files! When the version number changes, reset the RPM release number to '1' in the '''*.spec''' files ("Release:    1"). For several releases of the same version, increment the release number (the number after the dash in the RPM file name; we don't have release numbers for the tar files). ''I generally update the ChangeLog before updating the version numbers or NEWS, et c., files because the ChangeLog gives me a bird's eye view of what happened since the last release.''
#* Then to write the NEWS file, just read over the new ChangeLog entries and summarize. In the old days of CVS, the logs automatically included the names of the changed files, but subversion and git don't do that.
#*libtool versioning rules: What the ''CURRENT[:REVISION[:AGE]]'' string passed to ''libtool means:'' (Note these are set using variables in the configure.ac script.)
#* Make sure that the version number is set in the '''configure.ac''' and '''*.spec''' files! For the BES handlers, the version information is also int he Makefile.am (look for the '''M_VER=''' line). When the version number changes, reset the RPM release number to '1' in the '''*.spec''' files ("Release:    1"). For several releases of the same version, increment the release number (the number after the dash in the RPM file name; we don't have release numbers for the tar files). ''I generally update the ChangeLog before updating the version numbers or NEWS, et c., files because the ChangeLog gives me a bird's eye view of what happened since the last release.''
#**No interfaces changed, only implementations (good): ==> Increment REVISION.
#* libtool versioning rules: What the ''CURRENT[:REVISION[:AGE]]'' string passed to ''libtool means:'' (Note these are set using variables in the configure.ac script.)
#**Interfaces added, none removed (good): ==> Increment CURRENT, increment AGE, set REVISION to 0.
#** No interfaces changed, only implementations (good): ==> Increment REVISION.
#**Interfaces removed or changed (BAD, breaks upward compatibility): ==> Increment CURRENT, set AGE and REVISION to 0.
#** Interfaces added, none removed (good): ==> Increment CURRENT, increment AGE, set REVISION to 0.
#**So how do you know? For C++, build a file of the methods and their arguments using ''nm .libs/libdap.a | c++filt | grep ' T .*::' | sed 's@.* T \(.*\)@\1@' > libdap_funcs'' and compare that using diff on the previous release's library.
#** Interfaces removed or changed (BAD, breaks upward compatibility): ==> Increment CURRENT, set AGE and REVISION to 0.
#*Make sure that '''README''', '''INSTALL''' and '''NEWS''' are updated (setting ''check-news'' in ''Makefile.am'' ''AUTOMAKE_OPTIONS'' will enforce this).
#** So how do you know? For C++, build a file of the methods and their arguments using ''nm .libs/libdap.a | c++filt | grep ' T .*::' | sed 's@.* T \(.*\)@\1@' > libdap_funcs'' and compare that using diff on the previous release's library.
#Run the tests, including the ''distcheck'' target.
#* Make sure that '''README''', '''INSTALL''' and '''NEWS''' are updated (setting ''check-news'' in ''Makefile.am'' ''AUTOMAKE_OPTIONS'' will enforce this).
#Check that the RPM targets are working. This is a lower priority item then the ''distcheck'' target because these targets seem pretty stable unless the packaging and distribution files are changed. If that is the case, these targets should be checked.
# Commit & Push these changes.
#Commit these changes.
# Make the tar file - '''make dist'''
#Merge 'down' to the release branch.
#* '''Sign''' the tar file. [https://scm.opendap.org/trac/wiki/SecureEmail See the help item on the main trac wiki page if you need instructions.]
#Make the tar file
#* Move the file to the web site for distribution.
#*'''Sign''' the tar file. [https://scm.opendap.org/trac/wiki/SecureEmail See the help item on the main trac wiki page if you need instructions.]
<!--- # Make the RPM - '''make rpm'''
#*Move the file to the web site for distribution.
#Make the RPM
#*'''Sign''' the RPM
#*'''Sign''' the RPM
#*Move to a directory on the web site and use script to move the RPM around (later, once all the RPMs are uploaded).
#*Move to a directory on the web site and use script to move the RPM around (later, once all the RPMs are uploaded). -->
#Update the web pages:
# Update the web pages:
#Tag the release:
# Tag the release:
#*I use svn="https://scm.opendap.org/svn" in the following and in my shell.
#* git tag -a version-<numbers> -m "Version <number>"
#*Use ''svn copy $svn/branch/<<package>> $svn/tags/<<package-name>>/<<release-number>>''
#*If this is the first release of <<package-name>>, you have to create the directory under ''tags'' using ''svn mkdir''.

Revision as of 02:58, 21 September 2015

Note that the old pages with the tables of version numbers are gone. Use the web pages themselves as documentation of what has or has not been built. For the current release, include grayed-out links to binaries we do plan to make but keep the grayed-out links in place for the current version only!

Here's how to make a source release:

  1. First, make sure that the source code you're using is up-to-date and that the software passes its tests and no outstanding tickets remain for the release milestone. Make sure make check -j9 and make distcheck -j9 work. Checking make rpm is useful for a beta release because it will find problems that can slow the process once the final edits are done and the RPMs are being built. Note that for the BES, or any software that requires parameters passed to configure, use DISTCHECK_CONFIGURE_FLAGS=... when you run make. A typical distcheck for the BES is make distcheck -j9 DISTCHECK_CONFIGURE_FLAGS=--with-dependencies=$prefix/deps and yes, it's a pain to type... For tests, using TESTSUITEFLAGS=-j9 will speed up the autconf/autotest tests if the version of autoconf supports parallel testing.
  2. Update the text documentation files and version numbers in the configuration files:
    • Update the ChangeLog file using the script gitlog-to-changelog which can be found with Google. If you're making the first ChangeLog entries, then you'll need to create the ChangeLog file first. Here's a key tip: When you're making the commit log entries, use line breaks so ChangeLog will be readable. That is, use lines < 80 characters long.
    • Then to write the NEWS file, just read over the new ChangeLog entries and summarize. In the old days of CVS, the logs automatically included the names of the changed files, but subversion and git don't do that.
    • Make sure that the version number is set in the configure.ac and *.spec files! For the BES handlers, the version information is also int he Makefile.am (look for the M_VER= line). When the version number changes, reset the RPM release number to '1' in the *.spec files ("Release: 1"). For several releases of the same version, increment the release number (the number after the dash in the RPM file name; we don't have release numbers for the tar files). I generally update the ChangeLog before updating the version numbers or NEWS, et c., files because the ChangeLog gives me a bird's eye view of what happened since the last release.
    • libtool versioning rules: What the CURRENT[:REVISION[:AGE]] string passed to libtool means: (Note these are set using variables in the configure.ac script.)
      • No interfaces changed, only implementations (good): ==> Increment REVISION.
      • Interfaces added, none removed (good): ==> Increment CURRENT, increment AGE, set REVISION to 0.
      • Interfaces removed or changed (BAD, breaks upward compatibility): ==> Increment CURRENT, set AGE and REVISION to 0.
      • So how do you know? For C++, build a file of the methods and their arguments using nm .libs/libdap.a | c++filt | grep ' T .*::' | sed 's@.* T \(.*\)@\1@' > libdap_funcs and compare that using diff on the previous release's library.
    • Make sure that README, INSTALL and NEWS are updated (setting check-news in Makefile.am AUTOMAKE_OPTIONS will enforce this).
  3. Commit & Push these changes.
  4. Make the tar file - make dist
  5. Update the web pages:
  6. Tag the release:
    • git tag -a version-<numbers> -m "Version <number>"
Retrieved from "https://docs.opendap.org/index.php?title=Source_Release_for_BES&oldid=11976"