Skip to content

How To: prepare a release

Igor Velikorossov edited this page Jan 24, 2021 · 12 revisions

GitExtensions uses semantic versioning for its releases. The basic workflow proceeds as follows.

  1. General development work is performed on the master branch. During this time, new features may be added to the product.
  2. In preparation for a release, a new branch is created with the name release/major.minor. For example, the branch release/<latest version> was created in preparation for the <latest version> release. These release branches are feature frozen; only small bug fixes are allowed to be added to one of these branches.

1. Working on version

  1. Work on the new version takes place in the master branch
  2. Merge all PR that ready for new version
  3. Create milestone for new version
  4. Assign bugs (especially all regressions), features to that milestone
  5. Update 3rd party tools (PuTTY remains - to be removed)
  6. Update copyright year if needed
  7. Fix all issues in milestone or move them to milestone 'Next version' if necessary

2. Preparing to release

  1. Freeze master branch for all PR's that add/change localized strings - that means do not accept any PRs that modify strings.
  2. Bump up the version in the master branch
  3. Create branch release/3.x in GitExtensions
  4. Announce on Transifex that new version is ready to ship in two(?) weeks. Remind that only the language in which the "User Interface (master)" translated 95% or more will be added in the installer.

3. Release RC (after couple of weeks from step 2)

  1. Create branch release/3.x in GitExtensionsDoc
  2. To pull latest translations from Transifex website run the following:
    <project root>\ powershell  .\.tools\transifex\DownloadTransifexTranslations.ps1
    
  3. Do a high level review of the updated translations
  4. Review changes in Setup\Product.wxs
  5. Create documentation version on Read the Docs site. See wiki
  6. Commit and tag it as annotated tag v3.x.0-RC[number]
  7. Create a pre-release and publish binaries
  8. Give users the relapse candidate to test it

4. Release final version

  1. Update version date in GitUI/Resources/ChangeLog.md and port it to master branch
  2. Commit and tag it as annotated tag v3.x.0
  3. Upload it with changelog to GitHub releases
  4. Update the 'latest' branch for GitExtensionsDoc to point to the release documentation. See wiki
  5. If after week no critical error reported update version and link in configdata branch for autoupdater
  6. Upload release to SourceForge
  7. Update README.md on master branch
    • version number in section Downloads
    • badge SourceForge downloads (latest) contains a version number