Software Development Process

Deployment

• ALL RELEASES (Core and extensions) WILL OVERWRITE ALL PREVIOUS RELEASES (maximum)
• Modify the installer for a L-II core release so that its associated uninstaller handles the case where it is the last release on the machine (low)
  • in that case, version-independent executables (such as those in LANDIS-II/bin folder) need to be removed. In fact, the whole C:\Program Files\LANDIS-II\bin folder should be removed, as well as the LANDIS-II folder itself.
• Modify Windows installer to use raster-driver admin tool to install Erdas 7.4 driver
• Create installer for Mac OS X (medium)
  • Perhaps miminally provide the L-II core package as a zip file in addition to Windows installer
• Allow the user to specify where L-II is installed (in other words, remove the hardwired use of the "Program Files" directory) (medium)
  • Very useful if user is not administrator (pretty typical on Vista)
  • Useful in computer labs (when doing training)
  • Essentially allow "LANDIS-II on a stick" (not as in MN state fair food, but on a USB drive). Stick drive into slot, and user can run L-II off drive).
• Fix installer bug on 64-bit Windows
• Add licenses for 3rd-party software to L-II installation
  • Start --> LANDIS-II --> 6.0 --> Documentation --> Licenses
  • web page with links to 3rd party licenses
• Add version and release numbering scheme into developer resources

Building (FLEL Developers ToolKit) (MAY BE REPLACED BY STANDARD IDE??)

• Determine if FLEL DevKit is no longer necessary if we can "standardize" VS2008 (Visual Studio 2008) MSBuild project files. MonoDevelop supports VS2008 project files. (top priority)
• Complete FLEL DevKit 4.0's official release (or at least beta 1 release)
  • Goals of this release:
    • Consolidate all info now in separate build files (sources.txt, references.txt, modules.txt, ...) into the project's single build file
    • Remove release information (type and number) from the build process, and place it in the project's deployment folder
• Allow a developer to specify different assemblies for a project's configurations
  • Motivation: to allow side-by-side installation of a project's release and debug configurations
• Automating the whole build process for LANDIS-II packages (core, biomass extensions)
  • Will eventually allow use of a build server
  • Automatic execution of tests, so developers can't forget to run them before deploying code
• Modify the Landis.build file so the developer can specify which core version a component is being built against.
• Consider renaming project.build include file as "cs-project.build" to indicate that it's a C# project
• Verify that project can be build on OS X with Mono

Testing

• Consider how NUnit projects use NUNIT_DATA_DIR and NUNIT_OUT_DIR environment variables
  • Investigate replacing them with a single environment variable: NUNIT_TEST_DIR
  • Would use new directory structure:

            NUNIT_TEST_DIR/
              test-assembly-name/
                data/
                  ...
                     input files used by test assembly
                  ...
                output/
                  ...
                     output files generated by test assembly
                  ...
    

• NUnit is placing Test-Results.xml in a project's test folder (where source code). Determine how to get it placed in some intermediate folder (e.g., test/output or in NUNIT_TEST_DIR/output)

Documentation

• Evaluate doyxgen system as cross-platform tool for generating documentation from comments in source-code. (high)
• Automate the process for building developer documentation for L-II core and libraries as well as Landis libraries.
  • These developer resources should be generated for each core release.
• Add a note to developer documentation about deploying debug configurations of an extension:
  • Assembly name can't be renamed because .NET runtime will complain that the manifest doesn't match