Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Partly this is intended as a checklist for the Kokua team to follow but we’ve chosen to make it a public page so that the work behind the scenes can come into the spotlight for a change

Between releases

  • Prepare the release content - this may be fixing bugs, adding new features, porting from other viewers or merging with the latest versions of the LL viewer or Marine’s viewer

  • Most work done on Kokua is associated with a Jira ticket which gives both traceability and automation when it comes to gathering the release content for documentation

  • Give the new version a cooling off period while it’s used by team members to check for any new problems - Kokua’s development team is too small for formal testing cycles however we try to make sure nothing’s been newly broken

  • Make sure it builds in all three variants on each of the three platforms supported - this is particularly important if we’ve just merged with the latest LL viewer or Marine’s.

  • Just before starting a release build make sure no-one’s got anything else to be included and all pull requests have been processed

Performing the actual builds

  • Apply tags in the main source repository for the new releases and update the release repository

  • Perform the builds using the release repository instead of the main repository or personal forks

  • Upload the builds to Sourceforge

  • Upload the builds to Bitbucket

Release administration

  • Check in Jira that all issues included in this release are in the right state and marked as being contained in this release

  • Rename the release from ‘Kokua Next’ in Jira to the release’s actual version

  • Set the release in Jira to released state

  • Create a new ‘Kokua Next’ release in Jira

  • Write the release notes, including automatically generated content from Jira, publish them here and link to them from the Release Notes index page

  • Make sure that the viewer mechanism which displays release notes when a new version is first launched successfully accesses this version’s release notes

  • Update the Downloads page with new MD5 values and links to the new downloads

  • Update the Sourceforge default download for each platform which will trigger email notifications to those subscribed

  • Write and publish the blog post here announcing the new build

  • Send an inworld group notice to announce the build

  • No labels