/
How does a new version happen?

How does a new version happen?

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

  • Decide what the justification is for a new release - typically this is keeping pace with a new release by LL or Marine but sometimes an intermediate release is warranted to deliver new functionality or an important bug fix

  • 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

Jira 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

Release administration

  • 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. The RLV variant is set as the default for each platform since it’s consistently the most popular download

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

  • Send an inworld group notice to announce the build