Button Button Button
Module Release Checklist

This checklist describes the release process of a component assuming it has a version in the format X.Y[.Z]

Once a release cycle is announced in the Kepler list, most of the tasks are supposed to be executed by developers with SCM commit access. But if you want to help with the checklist, tasks that can be executed by anyone with SCM read access are marked with a "(anyone)" tag. Just make sure you use the module SCM HEAD and report any issues in the Kepler list.

  1. Check merges on the module release branch and the trunk (project developers)
  2. Check pending bug reports and feature requests (anyone)
  3. Build for Linux/OSX/Windows
    1. Check the module dependencies (anyone)
    2. Check the module source (anyone)
      1. Module header comments
      2. Module public API comments
      3. _COPYRIGHT Attribute
      4. _DESCRIPTION Attribute
      5. _VERSION Attribute using the format projectname X.Y.Z
    3. Check the module documentation (anyone)
      1. [[Documentation Format]]
      2. Module name
      3. Version
      4. License
      5. What's new
        • Include the SCM delta based on the sum of resource histories.
      6. Release date
      7. References to [=LuaBinaries=] and its version
      8. Images (PNG, GIF)
      9. Module [[Dependencies]]
        • Dependencies names, sites and versions used with this module version
      10. Documentation Links
        • Links to previous versions. This may require the creation of a directory on the project site and the copy of the previous files to the directory corresponding to (http://servername/projectname/X.Y)
        • Download from [[LuaForge]] (http://luaforge.net/projects/projectname/files)
        • Links to Kepler Project Home (including the logos)
        • Links to the Kepler mailing list on the Contact Us section (on index.html) and on the left menu
        • Links to the Lua Site
        • Links to the module license page
      11. Validate XHTML and links. This can be done locally or remotely. If done remotely the files should be copied to a ''preview'' directory on (http://www.keplerproject.org/projectname/preview). A simple link checker can be found at http://validator.w3.org/checklink
      12. README
        • Reference to the project home page
        • Version number
        • Description of the directories and files
      13. Test the examples in the documentation
    4. Create the Rockspec (projectname-X.Y.Z-V.rockspec)
      • Check dependencies list
      • Check the version number in the file
    5. Test the binary build for Windows, Linux and OSX (anyone)
      • Make sure you don't have the SCM version of the project Rock installed
      • Use luarocks make rockspecs/projectname-X.Y.Z-V.rockspec
    6. Test the configuration (anyone)
    7. Test the installation (anyone)
    8. Execute the unit tests (anyone)
  4. SCM details (project developers)
    • Branch using rel_[0-9]_[0-9]_x
    • Tag using v[0-9]_[0-9]_[0-9]_[alpha|beta][2-9]
  5. Generate the tar.gz and zip archives (using the Distribution Format) (project developers)
    • modulename-X.Y[.Z].tar.gz
    • modulename-X.Y[.Z].zip
    • modulename-X.Y[.Z]-win32-[luaXY].zip
  6. Test the tgz and zip archives. (anyone)
    • Check included files
    • Check the install/build process.
  7. LuaForge project details (project admin)
    • Bug Tracker
      • Categories (API, Documentation, Other)
      • Groups (Version numbers)
    • Feature Requests
      • Categories (API, Documentation, Other)
      • Groups ("Next Release")
  8. Release files in LuaForge (project developers)
    • Create the release modulename-X.Y[.Z]
    • Release and Change notes (the line breaks have to be manually positioned)
    • Source tar.gz and zip files
    • Binary zip files for Windows
  9. Test the module Rock (project developers)
    • Update the tarball URL in the Rockspec
    • Remove any previous version of the rock in the local repository
    • Make sure you are using the rockspec with the updated tarball URL
    • Install the release version of the rock (luarocks make rockspecs/projectname-X.Y.Z-V.rockspec)
    • Generate the Rock files (luarocks pack projectname X.Y.Z-V) in the local rock repository
    • Generate a local repository to check the dependencies (luarocks install --to=temprocks projectname-X.Y.Z-V.rock)
    • Update the local repository manifest (luarocks-admin make-manifest .)
    • Upload the Rock files, manifest and index.html to the Kepler repository
    • Test the Kepler version of the Rock
  10. Submit the module Rockspec (project developers)
    • Send the Rockspec to the LuaRocks list
    • Wait for the Rocks upload and confirmation
    • Test the uploaded Rocks
  11. Upload to the project site (ftp.luaforge.net) (project developers)
    • Documentation
    • Logo and images
  12. Links on the Kepler wiki (www.keplerproject.org) (anyone)
    • [[Modules]] page
    • [[Releases]] page
  13. Update LuaForge project page (project admin)
    • Public Info
    • Trove version and scope
  14. Announce the module on the Kepler list (project admin)
  15. Announce on the modules on LuaForge as a news post (project admin)
    • LuaForge Home Approval (LuaForge admin)
  16. Announce the module on the Lua list (project admin)