-
Notifications
You must be signed in to change notification settings - Fork 34
Building a Release
- Install Visual Studio support for Installer Projects from here (works with 2019 also):
Follow the instructions here to enable command line building of the installer (works with 2019 also)
the Microsoft Visual Studio 2017 Installer Projects extension now includes a command line helper tool for making the registry setting much easier to apply Microsoft Visual Studio 2017 Installer Projects Example paths of the tool (based on the version of Visual Studio installed)
Professional Edition: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild\DisableOutOfProcBuild.exe
Community Edition: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild\DisableOutOfProcBuild.exe
From the README
This simple tool is meant to help users set the registry key needed to get around this error that can appear when building installer projects using command line builds: ERROR: An error occurred while validating. HRESULT = '8000000A' The tool is meant for Visual Studio 2017+ and sets this reg key for a particular installed Visual Studio instance for the current user. So if you're setting this on a build agent make sure to use the user account that the build will use.
Run "DisableOutOfProcBuild.exe help" for usage details.
There is automation available on GitHub to assist with the creation and publishing of a candidate release. Releases built on GitHub do not typically need to be virus checked before release because the build is performed using operating systems and images which are owned by Microsoft and in theory, should be trusted.
More information on the workflows can be found here.
In the Helios repo root, run build 1.6.BUILD.REVISION where BUILD is your build number and REVISION is your revision number.
This will create a tag that is the same as your build number and build the installer. The working directory must be clean with no pending changes or untracked files. The script may report the working directory is not clean when it is. This is because git sometimes needs to check it twice. Run the same build command again to proceed.
You can test install it by running install.
These are some checks that need to be done manually for release candidates, because we don't have automation for them.
-
Check all File Versions.
The quickest way is to just enable that column in Windows Explorer while looking at the installed build. -
Install on (PC or VM) with Windows built-in anti virus
-
Pick one:
3a. Install on (PC or VM) with AVG
3b. Install on (PC or VM) with BitDefender
3c. Install on (PC or VM) with MalwareBytes
-
Install on (PC or VM) running international Windows with different number format (commas instead of periods.)
-
Confirm files are created in correct Documents folder
-
Ensure no files from Plugins are duplicated to main install location or similar file placement issues
-
Uninstall
The publish.cmd script will copy the built files along with change notes to a local directory for publication to developers and testers via google drive or another sharing mechanism.
The required parameters are the tag which was built to create the installers that were built via build.cmd and a second version reference (commit-ish or tag) which identifies the previous released version. The changes file will be initialized with all the git changes from the previous version to the current tag.
Unless a third parameter with the value nogithub is supplied, the script will also create a draft release on GitHub and attach the assets.
The assets include
- Helios Installers (64 bit is implied), including Helios MSI and Keypress Receiver MSI) in a zip file.
- Helios32Bit Installers, including Helios32Bit MSI, in a zip file
- there are no thumb prints required because we have no mirrors and delivery is via https from GitHub
- versioned setup.exe files are generated for all these but not included, because we don't seem to require visual C++ runtimes any more and in any case Microsoft's download mechanism for these is broken (in a different way than before)
Currently, this script will need to be hacked up to remove references to the folder used by derammo to publish unreleased builds to google drive.
-
No open issues on milestone https://github.com/HeliosVirtualCockpit/Helios/milestone/2
-
No closed issues on milestone that still have tags indicating they require documentation or verification https://github.com/HeliosVirtualCockpit/Helios/milestone/2?closed=1
-
User-readable release notes have been copied from draft release to wiki https://github.com/HeliosVirtualCockpit/Helios/wiki/Change-Log
Instead of specifying a version number, run build test to build an installer from a dirty working directory. This build will always have the default build number but it can be installed (requires uninstalling previous versions) to test by running install.
Build logs are emitted as binary logs in these files:
- clean.binlog (From cleaning process)
- prebuild.binlog (From BuildMeFirst.sln build)
- build.binlog (From building of all assemblies)
- [no log] (From building of installers)
Binary log files have full detail in a compact format. See https://msbuildlog.com/
For a public release, create a unique milestone name ahead of time. This represents a target in the future that will become a public release. For example, the first release of 1.6 to use this nomenclature is called Release16600 https://github.com/HeliosVirtualCockpit/Helios/milestone/1, because it will be builds 1.6.6000 through 1.6.6009, until we get a release. The next one would be Release16601 and start at build number 1.6.6010.0.
Each release should also have a release candidate branch called "rc16600" and so on. This branch is based at the first release candidate build that must be feature complete and have all known issues targeting this milestone resolved. All subsequent builds on this branch become release candidates with increasing build numbers 1.6.6004.x, 1.6.6005.x, etc. until one is a public release. This public release can go from "pre-release" to "release" status on GitHub so that it becomes /releases/latest and therefore gets pushed to all users.
For a public release, create a unique milestone name ahead of time. This represents a target in the future that will become a public release. For example, the first release of 1.6 is called Release1630 https://github.com/HeliosVirtualCockpit/Helios/milestone/1, because it will be builds 1.6.3000 through 1.6.3099, until we get a release. The next one would be Release1631 and start at build number 1.6.3100.0.
Each release should also have a release candidate branch called "rc1630" and so on. This branch is based at the first release candidate build that must be feature complete and have all known issues targeting this milestone resolved. All subsequent builds on this branch become release candidates with increasing build numbers 1.6.3044.x, 1.6.3045.x, etc. until one is a public release. This public release can go from "pre-release" to "release" status on GitHub so that it becomes /releases/latest and therefore gets pushed to all users.
Holding a release as a "pre-release" means it is available for the public but won't get pushed.
Holding a release as a "draft" means it is available to team members for testing but not to the public. It can later become a pre-release or a release or it can get discarded.
Rebuilding a prior release for bug fixes can therefore also be done by building this branch. If the branch is eventually cleaned up, the build tag of the last release in the appropriate build number range can be used to recreate an equivalent branch.
Change notes / release notes are now only on the wiki and do not ship with the product. Update the change notes at Change Log before release. The product will have a link to this wiki page in the Profile Editor Help menu.
An example for creating the "resolved bugs" section for the change notes, using https://github.com/github/hub:
hub issue -s open --include-pulls -M Release1630 -f "- %t [%i](https://github.com/HeliosVirtualCockpit/Helios/issues/%I) (%as)%n"
hub issue -s closed --include-pulls -M Release1630 -f "- %t [%i](https://github.com/HeliosVirtualCockpit/Helios/issues/%I) (%as)%n"
Edit the titles in this list so they can be understood by users.
Download latest Helios from this repo