Revision as of 16:36, September 20, 2019 by Mgionet (talk | contribs)
Jump to: navigation, search

Hotfixrnscreating

A hot fix release is the release of a component version that includes corrections to that version. Often these corrections are to defects found by customers. Sometimes hot fix releases include new features. The new feature may be implemented to resolve one of the defects.

Unlike restricted release notes or pre-release notes, hot fix releases are part of the same cumulative release note as General (PA) releases.

Like General (PA) release notes, starting with 8.5, Hot Fix release notes can be delivered in online format. However, if the General (PA) release note is still in HTML, you add the hot fix release to the same cumulative HTML release note as used for the General (PA) release. If your 8.5 release note is not yet converted to online format, please contact Tanya Ivanova to begin that process.

Notes:

  • A hot fix presumes that the component has been first released as General (PA) for that major version (for example 8.5.x). If you have a situation where there is no General (PA) release listed, contact Pubs Editors.
  • If you have a hot fix that is now becoming a General (PA) release, see the "When Hot Fix Becomes General" section in Unusual Release Note Scenarios.
  • Technical Publications does not create pre-release notes for hot fixes. These early releases of hot fixes (sometimes referred to as an “untested hot fix”) either do not require an RN because they are not tested, or they might require a restricted RN, per agreement with the team and Software Delivery.
  • A patch release for a restricted release is still a restricted release. The Hot Fix freeze type only applies to code that is generally available and intended for multiple customers.

Hot fixes for General (PA) releases under shipping control

If the previous General (PA) release for a component is under shipping control, any following hot fix does not need to be identified as under shipping control in the release note. Hot fixes are not designated as under shipping control because:

  • The PM has to approve a customer to receive the General (PA) release.
  • Any hot fixes following that version will only help those who were already approved for the General (PA) release.
  • Adding Under Shipping Control to a hot fix would mean that every approved customer who wants the hot fix would have to receive approval from the PM prior to receiving it.

Procedure

  1. One or more defects are escalated to the PM or another Genesys representative and JIRA issues are opened.
  2. The PCT scopes the effort to fix and test the defects, assigns a hot fix version to the associated JIRA issues, and sets a target date for delivery of the hot fix version.
  3. The software is frozen by the developer. The developer adds proposed text for the release note in the Release Note field in JIRA about each fix. A component freeze form is generated using the XING database. As part of the process, the developer or Development Manager updates the JIRA status to “Resolved."
  4. Technical Writers track the need for a hot fix using JIRA and the associated Project Core Team meetings.
  5. As Developers update the text in the Release Note field, the writer reviews the text and revises if necessary to improve the wording. If the writer has questions about the proposed wording, the writer contacts the Developer to obtain clarification, using the Comment field in JIRA.
  6. The Technical Writer develops the hot fix content for the JIRA issues associated with this hot fix. See Release Note Content Details for details on the technical content of release notes.
    Note: If you have a scenario where it seems that there are no new features and no corrections for a hot fix, see the "When There Seems to Be No New Features and No Corrections" section in Unusual Release Note Scenarios.
  7. Using the RN generation tool, the writer generates the code (HTML, if RN is in HTML format, or Wikimarkup, if the RN is online).
  8. Typically, the writer provides Development with a draft RN for review first. After Development approves the technical content, the writer provides it to the Product Manager, QA reviewer, and a Customer Care person (if your team regularly works with someone from that group for your product) for their technical content approval. Approval is typically sent via email for tracking purposes. (Note: Customer Care is not an official approver of release notes though.)
    • If the RN is online, be sure that your reviewers have permission to access draft online content. This requires that they create an account on our docs.genesys.com site. See Wiki Access for information.
    • If the RN is in HTML format, you can attach the HTML RN to an email sent to reviewers.
  9. The Project Manager mediates any blocking issues regarding technical content between Development, QA, and Customer Care for your product to ensure final consensus and approval of the release note. Note: These reviewers are not approvers of grammar or design/format/template-related issues. The assigned writer/Technical Publications department is responsible for those areas.
  10. When the RN is approved by your Project Core Team, the writer sends it for a Peer Review (to another writer) to approve grammatical accuracy, quality, and clarity.
  11. Request an RN format check.
  12. If the Hot Fix has a deployment procedure:
    1. For an HTML RN, if your RN already has an existing Deployment Procedure, you update the Procedure as necessary to include the hot fix version. To the Hot Fix release entry in the cumulative RN, you add a link to the Deployment Procedure HTML. The standard wording should be, “Refer to the Deployment Procedure for this release to deploy the installation package within your environment.”
    2. For an online RN, the RN generation process should cover what to do. If not, contact Pubs Editors.
  13. For the Hot Fix date, specify the date that the IP Test form is published as Pass (by QA).
  14. When the IP Test form is published as Pass by QA , the writer does the following:
    • For online RNs, the writer publishes the RNs, per the Release Notes with JIRA Process.
    • For HTML RNs, until Box is fully implemented, the writer follows the procedures provided by Pubs Editors in an email as part of RN format checking. Note: When Box is fully implemented, this section will be updated.
    1. Using XING, you publish the RN Freeze Form for the release note. (Note: RN Freeze Forms are not required for RNs that are part of the v9.0 release where the Packaging Spec Freeze in XING value is set to N.)
  15. Following the hot fix release,
    • The writer verifies that the correct RN is posted on the product landing page on the docs.genesys.com website. Contact Pubs Editors if the correct version is not displayed.
    • For HTML RNs, the writer also posts a copy of the RN on \\Galaxy\tdoc_final\Current_RNs.
Comments or questions about this documentation? Contact us for support!