Creating a Patch for a Package

Introduction

This HOW-TO describes how to create a patch for a package. The following should be considered.
  • Patch files have the same format as package files.
  • Patch files have the following naming convention: PACKAGENAME_patch_PACKAGEVERSION-PATCHVERSION.zip
    • PACKAGENAME is the name of the package like "CSMain".
    • PACKAGEVERSION is the version of the package like "3.00".
    • PATCHVERSION is the version of the patch starting at 1. As an example, the first patch for package CSMain version 3.00 has the name "CSMain_patch_3.00-1.zip".
    • If not stated otherwise, all patches belonging to a release of a certain package are cumulative. That is, after installing the package, one needs to install the latest patch (the patch with the highest version number) for that package only.

Checklist for Creating a Patch

This checklist ensures a certain quality and makes sure that nothing is forgotten. Each time a patch is released, this list must be checked.

  1. Each time the software is changed, check the file ROOTPATH\Packages\Packages.xls.
  2. For the maintainer of package CSMain only:
    1. Update the diagram of the VI "CoreLib/CoreLib.version info".
    2. Remove everything below "my_stuff" from the cs-framework.lvproj
    3. Copy a recent version of the database file to the package CSMain.
    4. Use the electronic lookbook.
    5. Check the file CS_readme.txt.
  3. If the package is contained in a lvlib, think about the version of the package and set the version of the lvlib to the version of the package. Set the build number to the PATCHVERSION
  4. For LabVIEW software, open the "contents.vi" of the package and check that it is executable. Make sure, that all classes have been entered into the "contents.vis". Save the "contents.vi" and all other VIs and acknowledge to save changed sub-VIs.
  5. Try, that the software is still working. Load an object of each class in the framework and test it. As an example, send a "Ping" event to check, that the CLASSNAME.ProcCase method is executable.
  6. In general, no executables are built for patches.If required, build an executable of the package on Windows and Linux.
  7. Synchronize the local files and the files on the source code control system. Don't forget the binaries.
  8. Build the patch-package using the Packager of the package CSPackaging. In case the package does not have hand-made release notes, the Packager can create them for you.
  9. Submit the zipped package files to the SourceForge download site.
    1. add the zip file to PACKAGEVERSION of the PACKAGENAME
    2. use the logbook entry from SourceForge as "chang log"
  10. Eventually, update the documentation on this Wiki web.
  11. Check, that the download site is working properly by inspecting it using a web browser and by downloading and unpacking the package.
  12. Inform the people that you think are interested.
    1. update the "News" on the SourceForge site
    2. update the patch tracker on the SourceForge site
      • add an entry to identifying this patch
      • describe where to find the patch
      • if the patch is cumulative, "close" older patches
    3. update the "News" on the Wiki web
    4. keep the logbook up to date

-- DietrichBeck - 12 Jun 2007
Edit | Attach | Print version |  PDF | History: r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r1 - 2007-06-12, DietrichBeck
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)