CodeMirror/manuskript
1
0
Fork 0
mirror of https://github.com/olivierkes/manuskript.git synced 2024-05-04 13:02:36 +12:00
Code Issues Projects Releases Wiki Activity
Page: Steps To Create An Official Manuskript Release
Pages
Adding a Spellcheck Language Dictionary to Manuskript Bundle manuskript for OS X with Platypus Configuration Settings Storage Locations Contributing guidelines for developers Creating manuskript binary for Android and IOS Documentation Snippets Fullscreen Mode Home How To Directory How to Add Images to a Project How to Display Remote Pictures How to Enable Dark Theme How to Export with Manuskript and Post Process with Calibre How to format your project with book and research notes in separate root level folders How to keep track of important items How to run manuskript globally, from anywhere How to start a new project Import and Export capabilities Keyboard Shortcuts Notes for linux packagers: removable files Overview of Manuskript Menu Overview of Manuskript Panes Overview of Manuskript Right Sidebar Overview of Manuskript Settings Package Manuskript for Linux with PyInstaller Package Manuskript for Linux with Stdeb Package Manuskript for Linux with dpkg Package Manuskript for Linux with rpm Package Manuskript for Windows with PyInstaller Package Manuskript for Windows with wine Package manuskript for OS X Roadmap Run Manuskript from Source Code on Linux Run Manuskript from Source Code on Windows Run manuskript on OS X Steps To Create An Official Manuskript Release Submitting an issue on Github Technical Support Translate Manuskript [Packaging] Generate Windows binaries with pyInstaller (HowTo)
27 Steps To Create An Official Manuskript Release
Tobias Frisch edited this page 2023-12-14 14:30:50 +01:00
Table of Contents

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.11.0)
  • N is the upcoming version about to be released (e.g., 0.12.0)
  • N+1 is a release at some unknown point in the future (e.g., 0.13.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.

  4. INCORPORATE TRANSLATION UPDATES

  5. PREPARE CHANGELOG

    • Generate changelog.

      git checkout develop
github_changelog_generator -u olivierkes -p manuskript \
  --exclude-labels question,duplicate,invalid,wontfix,discussion \
  --token {MyChangelogGithubToken}

    • Edit CHANGELOG.md to adjust for release number.

  6. PREPARE SOURCE CODE FOR PRODUCTION RELEASE

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

    • Add the new release to resources/ch.theologeek.Manuskript.appdata.xml

    • Test that manuskript can start and open a project

    • Commit manuskript/version.py and CHANGELOG.md

      git status
git add manuskript/version.py resources/ch.theologeek.Manuskript.appdata.xml 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

  7. 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.

  8. PREPARE RELEASE PACKAGES

  9. UPLOAD RELEASE PACKAGES

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

  10. UPDATE PROJECT WEB SITE