Release process
This page describes the actions points and step to follow before major
releases. There are various time-dependencies, so read the whole page
before beginning any work. It may be sensible to create tickets for some
if not many of the following points.
Pull Request (PR) review
See Using Git, for more
information about our usage of git and github. Before merging code to
develop, each PR is reviewed. Follow a list of “best practices” in order
to speed up the review.
- Persons who work on the code
- Add to the ticket or to the PR what must be tested e.g. click
view, check that the viewer opens.
- If a Bio-Formats change, add to the PR the command that can be
used to test the reader, the images to use and where to find them
(if necessary), etc. (-Dtestng.directory=$DATA ...)
- If UI changes, add to the ticket a screenshot before implementing
the feature and one after. For new feature a movie can be more
suitable.
- PR opening.
- Add a comment
- with a list of tickets to be tested, use hyperlink.
- the potential tester(s) e.g. @qidane, @jburel
- PR review
- list the tickets that worked, use hyperlink
- list the tickets that did not work, use hyperlink. If necessary
add more feedback to the ticket or the PR.
Model
- Beginning of milestone: Create a log ticket to record every ticket
number corresponding to a model change.
- Prepare upgrade stylesheet before freeze.
- Freeze model at least 3 weeks before database Upgrade freeze. To allow
the propagation of those changes through the stack i.e. Bioformats, database,
tests, etc.
- Prepare downgrade stylesheet.
Database upgrade
- List of proposed changes to the database should be submitted at the latest 3
weeks before code freeze. To allow enough time to adjust the database.
- Preliminary testing phase.
Feature freeze (bug fixing only)
- Freeze at least 4 weeks before the scheduled release date.
- Code freeze should correspond if possible to the end of sprint or to
the middle of sprint (usually Thursday)
- All changes in API incompatibilities and changes to public strings
(re: i18n) should be finalized.
Testing
- Review tests
- BioFormats
- During development phase, keep track of files failing to import
submitted to the team.
- Confirmation all the appropriate images are in squig in test
images good.
- The evolution of test_image_good, this requires reviewing the
submitted images from qa that had previously failed but are now
successfully importing.
- The creation of the testing user story and file format tickets all
assigned with the correct details before testing starts.
- Email sent out with full list of images to test for that release.
- The confirmation and validation of any specific file formats
that require additional tests for specific fixes in the
release.
- Recording BUG:
- Ticket summary must start with the work BUG:
- Add ticket to the story corresponding to the testing phase.
- Add ticket to the current milestone
- Add ticket to the correct component e.g. OMERO.insight, OMERO.web etc.
- Review daily tickets w/o time or owner.
- Include testing of upgrades from previous versions.
- Review/Update known limitations through testing
- Jenkins MUST report all logs at ERROR level as failures.
Documentation
- Website
- Copy snapshot of documentation under products before any new documentation is added.
- If necessary, begin editing that private location. (Note this
requires more work). Apply all changes here in preparation for
release. Key Pages to review:
- Videos. Indicate the following at the beginning of the movie:
- Your name
- version of the software
- subject of the movie.
- If your video uses the terminal, format your terminal
to use Monaco 22pt, yes THAT BIG, pick colours with a good
contrast and turn off window transparency!
- Video formatting instructions are available on the internal docs.
- Documentation of all API/model changes
- All sphinx documentation
Release candidates
- Give new clients to internal/external testers XX weeks before release
- Set up a testing server for internal/external testers.
- Upgrade local production server XX weeks before release.
- Test all components from official zips (ImageJ, etc.)
- Check that all clients properly detect compatible server versions
Schema pre-release checklist
- XsdFu code generation
- Upgrade online validator
- Update fetch_content_from_git.sh
- Change develop URLs to master (FIXME)
Release
No pre-meeting releases; Need at least X week(s) before a major
event.
Update version numbers for release (There should only be a single
commit with this version number)
Tag the SHA1 of that single commit for release:
git tag -u "Josh Moore (Glencoe Software, Inc.) <josh@glencoesoftware.com>" -m "Release version 4.4.9" v.4.4.9
Push the tag to the official repository:
git push origin v.4.4.9
Checkout master:
Merge the newly created tag:
$ git merge v.4.4.9
Push to the official repository:
Update version number for the :doc:
UpgradeCheck </sysadmins/UpgradeCheck>. This is currently done
by connecting to the “feedback” database on necromancer. Following
info also under OMERO upgrade checks:
select * from registry_version;
update registry_version set version = '4.4.9';
Create builds with jenkins
Assuming the commit isn’t present.
git push origin v.4.4.9 develop
If commit is present, just click on “Build” on Jenkins
Mark build as “QA”, eventually as “Release”
Copy builds to /snapshots (currently manual)
This kicks off the VM build (automatically published to
/snapshots)
Rename the “latest-build” VM.
Publish website
- Archive Main Website Documentation for previous release (i.e. Move
old documentation to versioned URL)
- Move “copy_of_” documentation to be active
Announce on mailing lists and in news
Branching
- Rename “*-trunk” jenkins jobs to “*-<RELEASE_NAME>”
- Add bioformats branches to /hudson/bioformats.git/git-fetch.sh and
hooks/post-receive
Post release
- Change reports in left-bar of trac
- Update any deployed servers (ask Josh)
- Update online validator (See #8640 for an example)
Demo server
- Contact KIT if they are willing to do upgrade.
- Notify demo users when upgrade will take place.
- Submit any necessary configuration options while upgrading.
- Test demo server.
- Email announcement.
== Items in progress ==
Unpolished TODOs for review/expansion:
== Later ==
* Remove branch
== TBD ==
* Branching policy
* Integration/propagation of release to Glencoe