Skip to content

Release Plan

Jump to bottom
Frank Dana edited this page Nov 18, 2019 · 58 revisions

This document contains all the steps needed for a new release of OpenShot Video Editor. Many things need to happen in a specific sequence during a release, and this is my attempt to document the process. Be sure to complete the Release Testing Plan first.

1. Call for Translations

Before we can start the release process, we need to update the POT translation template (https://github.com/OpenShot/openshot-qt/blob/develop/src/language/OpenShot.pot), which contains all translatable strings contained in OpenShot. Run the following script to update the template file:

python3 src/language/generate_translations.py

Once the OpenShot.pot file is updated, merge this change into the develop branch. LaunchPad.net no longer automatically detects a change in this file, so we will need to manually upload the POT file. Translators can use LaunchPad to translate these English phrases and words into their own languages. If you are interested in helping translate OpenShot, instructions are available.

  • 1.1 - Run the generate_translations.py script
  • 1.2 - Merge OpenShot.pot into develop branch
  • 1.3 - Manually upload OpenShot.pot to LaunchPad
  • 1.4 - Verify new translatable strings appear on LaunchPad
  • 1.5 - Notify the community (Facebook, Blog post, E-mail [email protected])

2. Download Translations & Credits

Allow the community at least 7 days (and more if possible) to answer the call and submit translations through LaunchPad. Each night, translations are automatically committed to a Bazaar code branch (https://bazaar.launchpad.net/~openshot.code/openshot/translations-2.0/). Run the following commands on that branch to generate the final translation files needed by OpenShot:

bzr branch lp:~openshot.code/openshot/translations-2.0
cd translations-2.0
python3 compile.py

This will create the following files:

  • openshot_lang.qrc (a resource file with a list of supported languages)
  • src/locale/OpenShot/output/OpenShot.[LANG-CODE].qm (one of these files for each language)

Now copy those files into the openshot-qt source code, into the /src/language/ folder. Next, run the following commands for the openshot-qt Git repo:

cd openshot-qt
cd src/language
make
pyrcc5 openshot_lang.qrc -o openshot_lang.py

That will modify the openshot_lang.py file with all the latest translations. Now merge those changes into the develop branch.

  • 2.1 - Pull or branch translations-2.0 bzr branch
  • 2.2 - Run compile.py script
  • 2.3 - Copy openshot_lang.qrc and *.qm files to openshot-qt (/src/language/ folder)
  • 2.4 - Run pyrcc5 openshot_lang.qrc -o openshot_lang.py from the src/language folder
  • 2.5 - Download donors and contributor credits into /src/settings/contributors.json
  • 2.6 - Merge these changes into openshot-qt develop branch

3. Test Translations

Now that the openshot-qt develop branch has updated translations, we need to verify there are no issues in the translations, such as missing placeholders (%s) or the wrong number of placeholders. Run the following script to test all translation files:

python3 src/language/test_translations.py

If any errors are reported, fix them in LaunchPad and run through the above Download Translations instructions again.

  • 3.1 - Run test_translations.py script
  • 3.2 - Fix any reported issues on LaunchPad

4. Create Release Branch

Now that we have verified all translations are updated and working correctly, we need to create a release branch for all 3 OpenShot Git repos (libopenshot-audio, libopenshot, and openshot-qt). Run the following commands for each Git repo folder (with the current date - YEAR-MONTH-DAY):

cd [GIT REPO FOLDER]
git checkout develop
git pull
git checkout -b release-20190320   (Replace the Date)
nano src/classes/info.py (increment VERSION, MINIMUM_LIBOPENSHOT_VERSION, and DATE for openshot-qt)  OR
nano CMakeLists.txt (increment version number for libopenshot-audio / libopenshot)
git push

This will create and push a release branch to GitHub for each of these OpenShot repos. Our build servers will detect these new branches, and build libraries, package dependencies, and create installers for Linux, Mac, and Windows. These installers will be uploaded automatically to GitHub with the naming pattern: OpenShot-v[VERSION]-release-candidate-[DATE], and will appear on https://www.openshot.org/download/ (under Daily Builds).

  • 4.1 - Create release-DATE branches (libopenshot-audio, libopenshot, and openshot-qt)
  • 4.2 - Verify version numbers updated
  • 4.3 - Verify build servers succeeded
  • 4.4 - Verify release-candidate installers appeared on website

5. Call for Testing

It's time for some serious testing! Share the links to our new release candidates with the community (primarily Zulip), in hopes that a few people will help test them out. We have an easy-to-follow testing plan, with test media files available to make this testing process as consistent as possible. Successful tests should be verified on all 3 OSes before continuing. New release candidate commits will likely be needed for fixing bugs and continuing to update translations. Repeat these steps until all testing plans are successful on all OSes.

  • 5.1 - Notify community (on Zulip) of release candidates
  • 5.2 - Run testing plan successfully on all 3 OSes (Linux, Mac, and Windows)
  • 5.3 - Fix any bugs in release branch (and repeat these steps again)

6. Create Changelog and Update AppData File

This is currently a manual process, to copy all Git logs, and create a hand-cleaned version (for each repo), without all the noise of merging, similar commits, mistake commits, etc.... I also reorder the log in order of importance (at least based on my perception). These change logs are used in a few places (such as the GitHub release page and LaunchPad release page), and it's nice to have them done before moving forward with the release. Run the following commands to output the git log for each repo or download them from the release candidate artifacts on GitLab (build/install-x64/share/*.log):

cd [GIT REPO FOLDER]
git log $(git describe --tags --abbrev=0)..HEAD --oneline --pretty=format:"%C(auto,yellow)%h%C(auto,magenta)% %C(auto,blue)%>(12,trunc)%ad %C(auto,green)%<(25,trunc)%aN%C(auto,reset)%s%C(auto,red)% gD% D" --date=short > "[GIT REPO FOLDER].log"

The day of the release (but prior to packaging the final builds), a tag needs to be added to the AppData file for OpenShot. At the bottom of the file, in the <releases> stanza, add a new <release.../> tag above the existing ones. (The format is pretty self-explanatory.) Run the following command to edit the file:

cd [openshot-qt GIT REPO FOLDER]
nano xdg/org.openshot.OpenShot.appdata.xml
  • 6.1 - Run script to generate change log files for each repo
  • 6.2 - Manually remove noise and duplicate entries
  • 6.3 - Re-order based on perceived importance
  • 6.4 - Save these files and place them in a safe place (we'll need them soon)
  • 6.5 - Add the new release to xdg/org.openshot.OpenShot.appdata.xml

7. Create Pull Request (to master)

Now that we have verified our release candidate has successfully passed our testing plan on all 3 OSes, it is time for the moment of truth! It is time to create a PR (Pull Request) to merge our release branch into our master branch. Once this has been done, our build servers will detect that the master branches have been updated, and will prepare the final builds, dependencies, and installers. A new Release will also be created on GitHub, which will contain all the installers just created. Once completed, each installer should be downloaded and verified, to be sure nothing was interrupted during the upload. These installers do not automatically appear on https://www.openshot.org/download/ (this will happen at a later time).

  • 7.1 - Create PR (master <= release) for each repo
  • 7.2 - Merge them in order (libopenshot-audio, libopenshot, and openshot-qt)
  • 7.3 - Verify all builds succeed
  • 7.4 - Verify all builds are uploaded to the correct GitHub release page

8. Tag Release

Tag the final commit in the master branch with the following pattern: v[VERSION]. Run the following commands for libopenshot and libopenshot-audio repos, or use GitHub to create these tags:

cd [GIT MASTER FOLDER]
git tag v[MAJOR-MINOR-PATCH]
git push origin --tags
  • 8.1 - Tag each Git repo with the version number (for example: v2.0.0)
  • 8.2 - Push tags to GitHub
  • 8.3 - Verify all tags appear on GitHub

9. Create Archives (tar.gz) for LaunchPad

Historically, we have always uploaded source code archives on LaunchPad.net. Run the following commands to create the archive files for each repo folder.

cd [GIT REPO FOLDER]
git checkout master
git pull
git archive --format=tar.gz -o [GIT REPO]-[VERSION].tar.gz HEAD

10. Create Pull Request (back to develop)

We now need to merge our master branch back into our develop branch, so our develop branch can also contain all the final changes from our release.

  • 10.1 - Create PR (develop <= master) for each repo
  • 10.2 - Merge them in order (libopenshot-audio, libopenshot, and openshot-qt)
  • 10.3 - Verify all builds succeed

11. Debian Packaging (for Daily PPA)

Our daily and stable PPA (used for distributing OpenShot for Debian-based Linux distros) needs to be updated for each new release. Our daily LaunchPad recipe only uses source code from the develop branch, so be sure to merge master back into develop before this step. Run the following commands to update the Debian packaging.

git clone git+ssh://[email protected]/openshot-packaging
cd openshot-packaging

# Libopenshot-audio Packaging
cd libopenshot-audio/debian
dch -i          # Add a new revision at the top of the Debian changelog file
nano control    # Update SO and Replaces sections
git mv libopenshot-audio[OLD-SO].install libopenshot-audio[NEW-SO].install
git add changelog control
git status      # Verify all files are staged for commit
git commit -m 'New upstream release of libopenshot-audio for [VERSION]'
git push launchpad

# Libopenshot Packaging
cd libopenshot/debian
dch -i          # Add a new revision at the top of the Debian changelog file
nano control    # Update SO and Replaces sections
git mv libopenshot[OLD-SO].install libopenshot[NEW-SO].install
git add changelog control
git status      # Verify all files are staged for commit
git commit -m 'New upstream release of libopenshot for [VERSION]'
git push launchpad

# Openshot-qt Packaging
cd openshot-qt/debian
dch -i          # Add a new revision at the top of the Debian changelog file
nano control    # Check if any changes are needed
git add changelog control
git status      # Verify all files are staged for commit
git commit -m 'New upstream release of openshot-qt for [VERSION]'
git push launchpad

12. Update Stable PPA

Now that we have verified the daily PPA has updated (and correctly versioned) packages, we need to copy them to our stable PPA. Choose Stable PPA in the first drop-down, Same Series in the second drop-down, and Copy Package in the final selection. Then click the Copy Packages button.

13. Update Develop Version

We need to bump the development version number, so users running the daily build will have a different version number than our release. Run the following commands for the openshot-qt Git repo:

cd openshot-qt
git checkout develop
git pull
git checkout -b update-version
nano src/classes/info.py (append '-dev' to version number for openshot-qt)
git push

14. Write Blog Post

It's time to put on the "marketing" hat and adapt our changelogs into a beautiful, readable, and enjoyable promotion of the latest OpenShot features, bug fixes, and improvements. This is also a great opportunity to encourage community engagement with our project, meet new volunteers, find new translators, and generate donations to help fund OpenShot infrastructure costs.

  • 14.1 - Create demo video (optional but highly desirable)
  • 14.2 - New blog post (with screenshots if needed)
  • 14.3 - Do not publish the blog post yet (this happens at a later point)

15. Website Release

Login to the openshot.org admin page (URL not displayed here), and create a new Release record. Enter the new version number, the current date, and the URL to the announcement blog post. This will update the current version on our website, will make out download page link to the new installers, and will notify all running clients a new update is available (on launch of OpenShot). After this is done, we have officially released OpenShot!

16. Publish Announcement

Now let's publish our blog post and let the world know about our latest release! Be creative and have fun with these posts. And listen carefully to any immediate feedback, in case users are having difficulty downloading or installing OpenShot.

  • 16.1 - New Patreon post (linking to download page)
  • 16.2 - Publish blog post
  • 16.3 - Post Facebook, Twitter, Linux subreddit, and social media accounts (link to blog post)
  • 16.4 - Respond to comments and observe if users are able to successfully run the new release

Want to help improve OpenShot (and make some friends in the process 🤗)? Please consider joining our open-source team by filling out this quick contributor form and introduce yourself! All volunteers are welcome, regardless of skills or skill level. Let's build something amazing!

Home

1. Community

2. Product

3. Troubleshooting

Clone this wiki locally