Building Packages

Introduction

A package is just a collection of files. It serves to group files together and to distribute those files. Of course, a package can depend on other packages. Each package has a responsible maintainer that builds the package. The process of building a package is, in fact, the process of releasing software. This HOW-TO describes how to build a package.

Checklist for Releasing a Package

This checklist ensures a certain quality and makes sure that nothing is forgotten. Each time a package is released, this list must be checked. Version numbers always have the format A.C.B.D, whith the meaning of A as the major version number, B as the minor version number, C as the patch (fix) number and D as the build number.

1. Each time the software is changed, check the files
   1. ROOTPATH\Packages\Packages.xls, and
   2. ROOTPATH\LVXXX\GPL\Projects\cs-framework\Classes.xls.
   3. Check the release notes of the package.
2. For the maintainer of package CSMain only:
   1. Update the diagram of the VI "CoreLib/CoreLib.version info".
      • In case of a major release, change the version number.
      • In case of a patch, add ".NN" to the version number and change the date of the release.
   2. Remove everything from the CS_Contents_User.vi.
   3. Remove everything below "my_stuff" from the cs-framework.lvproj, except CS_Contents_User.vi and the folders otherStuff, instr.lib, applicationBaseClasses, deviceClasses, GUIClasses and VI templates.
   4. Copy a recent version of the database file to the package CSMain.
   5. Use the electronic lookbook.
   6. Check the file CS_readme.txt.
3. Not only for classes, update the documentation at least in the library description of the class. Take care to include the license agreement in the properties of the corresponding library (lvlib). Include name of author and maintainer.
4. 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. In case of a pre-release (like "alpha"), set the build number to "9999" (beta: 9998, ...)
5. What about the "INFO2SF" keyword?
6. It may also be a good idea to copy the following files to the main folder, where the library is located.
   1. license agreement (if required)
   2. CLASSNAME_db.ini (if required)
   3. CLASSNAME_mapping.ini (if required)
   4. CLASSNAME_SVTemplate.csv (if required)
   5. CLASSNAME.gog (if required)
7. Take care to fulfill the coding conventions.
8. 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.
9. 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" and/or "GetVersionOfLibrary" event to check, that the CLASSNAME.ProcCase method is executable. Take care to try the software on all supported platforms.
10. If required, build an executable of the package on Windows and Linux.
    1. Don't forget to change the version number in the build specifications.
    2. Don't forget to check the list of souce files to be included.
    3. Maintainer of package CSMain only: Don't forget building executables of the CSAccessServer.
11. Try, that the executable is working. As an example, load an object of each class and test it by sending a "Ping" to each object.
12. Eventually, you would like to delete "dimWrapper.log" files, that have been created accidentally.
13. Synchronize the local files and the files on the source code control system. Close LabVIEW and save all unsaved things prior to synchronizing.
    1. Don't forget the binaries.
    2. Add the SCC revision number to the elog.
14. For the maintainer of package CSMain only:
    1. Create a tag in the source code control system for the release.
    2. Update the documentation on the source code control system in this web.
    3. Add the SCC revision number to the CS_release_notes.txt
15. Build the package using the Packager of the package CSPackaging.
    1. In case the package does not have hand-made release notes, the Packager can create them for you.
    2. Important: The change-log must be added to the release notes. Put the change-log into a seperate file (eventually together with hand-made release notes and add it when building the package). Unfortunately SourceForge no longer supports the feature of changelog explicitely.
    3. Please make sure not to include material (code, binaries, documentation) with copyright (like third-party instrument drivers) in the package except you have an explicit permission to do so. Of course, material with copyleft under the GNU Public License may and should be included.
16. Submit the zipped package files to the SourceForge download site.
    1. add the zip file
    2. add the release notes contained in the zip file and rename them to "readme.txt"
    3. check, that the download site is working properly by inspecting it and at least comparing the size of the file to download with the original one on the local disk.
    4. in rare cases, you may add a installer...
    5. eventually "close" patches, feature requests, ..., to prior versions of the package
    6. eventually update the list of our internal CSDownloadLinks as well as the version specific download pages
17. Update the documentation
    1. on this Wiki web and
    2. eventually the class documentation on the "Frontpage-web".
    3. list of classes on the version specific class list ("INFO2SF")
18. Don't forget the changed "Packages.xls" file.
19. Inform the people that you think are interested.
    1. update the "News" on the SourceForge site
    2. keep the logbook up to date
    3. update the "News" on the Wiki web
    4. in case of bug fix, inform the person who had reported the bug
    5. for very important things send a mail to the mailing list
20. Eventually, and in case of an instrument driver, update the instrument driver download page at your institute.

-- DietrichBeck - 27 Oct 2008