Steps To Create An Official Manuskript Release

Following is a DRAFT proposal for the steps to follow when creating an official manuskript release.

These steps are intended to be a work in progress and to be updated as more experience is gained.

Assumptions

Development Process

• All enhancements are made to the develop branch
• The master branch represents the current production release

Version Numbers

• N-1 is the current production release (e.g., 0.9.0)
• N is the upcoming version about to be released (e.g., 0.10.0)
• N+1 is a release at some unknown point in the future (e.g., 0.11.0)

Steps

1. FINISH DEVELOPMENT AND TESTING

   • Complete development, documentation, and testing for upcoming release.

2. CREATE RELEASE AREA AND CLEANUP MILESTONES FOR ISSUES AND PULL REQUESTS

   • Create new draft release area for N.

   • Create future release milestone N+1.

   • Close current project release milestone N-1.

   • Ensure all issues and pull requests are completed for milestone N, or move to a different milestone.

3. NOTIFY TRANSLATION TEAMS OF UPCOMING RELEASE

   Weblate is based on GitHub develop branch. It needs updates pulled to it whenever new strings are added for translation.

   • Contact (how???) translation members about upcoming release in 1 week?

     During this week no changes to strings are allowed.
     Ideally no changes are made to the source code other than translation updates.

   • Incorporate translation updates

     • Install Weblate client
     • How to fix merge conflicts in translations?
     • Weblate repository pull page

4. PREPARE CHANGELOG

   • Generate changelog.

     git checkout develop
     github_changelog_generator -u olivierkes -p manuskript \
       --token {MyChangelogGithubToken}
     

   • Edit CHANGELOG.md to adjust for release number.

5. PREPARE SOURCE CODE FOR PRODUCTION RELEASE

   • Update manuskript/version.py version number for production release

   • Test that manuskript can start and open a project

   • Commit manuskript/version.py and CHANGELOG.md

     git status
     git add manuskript/version.py CHANGELOG.md
     git commit -m "==========   manuskript-x.y.z   =========="
     

   • Check git tree

     gitk --all
     

   • Push updates to the develop branch

     git push
     

   • Wait for Travis Continuous Integration builds/tests to complete

6. ADD DEVELOPMENT CHANGES TO MASTER BRANCH FOR OFFICIAL RELEASE

   • Merge develop branch into master branch.

      git checkout master
      git merge develop
     

   • Stamp production version label on git repository

     git tag -a X.Y.Z -m "manuskript-x.y.z release"
     

   • Push updates and tags to the git repository

     git push
     git push --tags
     

   • Wait for Travis Continuous Integration builds/tests to complete

   • IF need to retrigger Travis CI builds/tests then check for Restart build button on Travis CI. Alternatively change tag with git tag -a X.Y.Z -m "Manuskript X.Y.Z" --force and re-push with git push --tags --force commands.

   • Note that the automatic build of the macOS X package appears to automatically publish the release for N.

7. PREPARE RELEASE PACKAGES

   • GNU/Linux

     • .deb - Manually create with ./package/create_deb.sh script (See Package Manuskript for Linux with dpkg)
     • .rpm - Manually create with ./package/create_rpm.sh script (See Package Manuskript for Linux with rpm)

   • Mac OS X

     • Automatically generated by Travis CI .travis.xml (See Package Manuskript for OS X with PyInstaller)

   • Windows

     • Manually create with Package Manuskript for Windows with PyInstaller

8. UPLOAD RELEASE PACKAGES

   • Ensure all packages are uploaded to release area whether automatically or manually created.

9. UPDATE PROJECT WEB SITE

   • Update Download page

   • Announce new release on http://www.theologeek.ch/manuskript/