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 64-bit and 32-bit 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 release history
- make
sure
settings3.1.html
andlangs3.1.html
exists,settings.html
is the same assettings3.1.html
- deploy the website
- create a
release
rel3.1
fromrel3.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