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 :doc:`/developers/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 - Jenkins Linux & Windows "start" jobs **should be passing** - See: :jenkins:`job/OMERO-trunk-components`. - 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. Bio-Formats freeze (no jar changes) ----------------------------------- - Freeze Bio-Formats **at least 1 week** before the actual release Documentation ------------- .. _Main Page: `Open Microscopy Environment`_ - 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: - `Main Page`_ (no copy. Update on Release) - Products - :omero_plone:`Feature List Page ` - :omero_plone:`Big Images Support ` - :omero_plone:`About Omero ` - :omero_plone:`Volume Viewer in OMERO.web ` - :downloads:`Downloads <>` - :omero_plone:`Screenshots page ` - :about_plone:`Contributors ` - Road map page: - :about_plone:`Roadmap ` - :about_plone:`Version history ` - Movies page ? - :about_plone:`What OMERO ` - Upgrade page - i.e. add section to :doc:`/sysadmins/server-upgrade` including database upgrades, etc. - 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 ------- .. |releasetag| replace:: v.\ |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: .. parsed-literal:: git tag -u "Josh Moore (Glencoe Software, Inc.) " -m "Release version \ |release|" |releasetag| - Push the tag to the official repository: .. parsed-literal:: git push origin |releasetag| - Checkout master: :: git checkout master - Merge the newly created tag: .. parsed-literal:: $ git merge |releasetag| - Push to the official repository: :: git push origin master - Update version number for the :doc: `UpgradeCheck `. This is currently done by connecting to the “feedback” database on necromancer. Following info also under :doc:`/sysadmins/UpgradeCheck`: .. parsed-literal:: select * from registry_version; update registry_version set version = '\ |release|'; - Create builds with jenkins - Assuming the commit isn’t present. .. parsed-literal:: git push origin |releasetag| 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 "\*-" - 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 :ticket:`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