Skip to content

Release process

Krzysztof Kowalczyk edited this page Oct 25, 2015 · 8 revisions

Release criteria

We don't want to make releases too often as updating is a bit annoying. We make a new release if there are significant user-visible changes since the last release.

How to make a new release

Substitute 3.1 for an actual version. Steps when doing a new release:

  • create a release branch rel3.1working. Only small bug fixes go here and it's meant as a stabilization branch
  • stress test both 64bit and 32bit versions
  • test other stuff
  • build and upload a release .\scripts\build-release.bat
  • verify have been uploaded by downloading, installing, testing
  • test crash-testing works (SumatraPDF.exe -crash-on-open, open a file, check crash report has been submitted)
  • update website for the new version
  • bump version in sumatra.js
  • update news.html
  • make sure settings3.1.html and langs3.1.html exists, settings.html is the same as settings3.1.html
  • deploy the website
  • create a release rel3.1 from rel3.1working using GitHub UI. This also creates a corresponding tag and source code .zip and .tar.gz archives
  • make an announcement on the forum
  • tweet that announcement
  • write a blog post
  • after a week or so trigger auto-update check

Testing crash reporting:

  • download the binary (both 32bit and 64bit)
  • run with -crash-on-open flag
  • open a document
  • verify crash report was submitted

Testing PdfPreview.dll:

  • preferably starting with a clean machine, install Sumatra
  • in explorer, navigate to a folder that has PDF files
  • switch view to thumbnails
  • in time a preview should show up

Currently we only ship PDF preview

Testing PdfFilter.dll:

  • put a PDF file with fairly unique text in Documents folder
  • allow time for it to be scanned
  • search for that unique text from task bar, choose "My Stuff" on Windows 10
  • that document should be found
You can’t perform that action at this time.