Restricted Release Note

Important

As of July 2021, all IX folks can submit Restricted RNs to Production Builds once they have been approved by your PCT, peer edited, and format checked by Pubs Editors. Steps 9 through 12 explain the process. Examples of the email to Production Builds are also provided after the procedure.

Important

In May 2020, a new automated procedure for Internal Announcements was introduced that leverages the IP Test forms for IPs and CDs of the General and Restricted type. Sometime after QA publishes the associated form, the Project Manager (usually) completes various fields under the PA Planning section of the form, including the PA date. Based on this information the announcement email is generated and sent out. Previously, Project Managers created the email announcements manually. This change does not impact writers directly because writers only publish the documentation and RNs when they see the Software Delivery announcement.

However, a few things are worth noting:

• For your Release Notes, if your team hasn't yet communicated the date, you can use the date in the IP Test form to begin with. You can later confirm the date with your team or from the Internal Announcement.
• Two other fields, called PM Control for New orders and PM Control for All orders (also usually populated by the Project Manager), indicate whether there is any PM control. Writers can use this information to determine if they need to indicate PM control in the Restrictions field of the RNs.

It is likely that the information in the form is not only tied to the automated Internal Announcement but to Software Delivery processes as well. Given this, if the information is not filled out in the form, it is possible that neither the Internal Announcement or the Software Delivery will be generated, and you won't have the notification to publish your documents.

Important

• Currently, restricted RNs are still delivered in HTML format.
• If you have a restricted component that is now becoming a General (PA) release, see the "Restricted Release Becomes General" section on the following page: Unusual Release Note Scenarios.
• A patch release for a restricted release is still a restricted release. The Hot Fix freeze type only applies to code that is General (PA) and intended for multiple customers.

A release can be classified by Product Management as restricted for a number of reasons; for example, the release can have limited testing, a limited customer base, or limited platform support. A restricted release does not go into the cumulative RN; it is a separate RN. For Technical Publications, a restricted release follows this process:

1. The PCT schedules and tracks the restricted release.
2. The software is frozen by the developer. The developer adds Release Notes comments in the Release Note field or as a Comment in the JIRA issues about each fix or change that is deemed relevant to customers by the PCT. A component freeze form is generated using the XING database that informs you of the version number of the component. Using that version in JIRA, you can also determine what issues are addressed in that restricted version. As part of the process, the developer or Development Manager updates the JIRA issue status for each issue to Resolved for QA to test. QA changes the status to Closed if the issue works as expected and can be documented in the release note. If an issue is not fixed or working as expected, it will be left open and Development and QA will let you know via the JIRA issue if it needs to be documented as a Known Issue.
3. The writer's next step depends on the nature the restricted release.
   • If the product and component are new, never released before, and its first release is restricted, you obtain the HTML template (link below) and start from scratch to create the RN.
   • If the product has been released before but as restricted, you get the previously created HTML restricted Release Note and add the new section for that later version to the top of the release note just as you would add a new section for a new release in a General (PA) Release Note. Note: This type of “cumulative” restricted RN is most often used for new products that have never been released as General (PA), Early Adopter customers for products or iterations that have a more limited release, and, in exceptional circumstances, for internal development (for example, Designer). Check with your PCT to confirm that this cumulative format is appropriate.
   • If the product/component has been released before as General (PA), you obtain the restricted HTML Release Note template and create the restricted RN with only that restricted version. You do not take the General (PA) release note and add a restricted section.

   The HTML template is stored in SharePoint here.

4. For a new restricted RN, the writer decides on a reasonable name for the restricted RN. The file name for a restricted RN mirrors the file name for the cumulative General (PA) release note with the release version number and, possibly, the client name added for identification. For example, “mm-gcld-dr-fb90rn_9000307.html” or “mm-gcld-dr-fb90rn_9000307-vodafone.html”. Confirm the file name with Pubs Editors.
5. The writer develops technical content based on the JIRA information for issues associated with this restricted release. The Technical Writer may contact the appropriate Development and QA engineers to request any needed information. See Release Note Content Details for details on the technical content of RNs.

   Note: The content in the restricted RN is specific to that restricted release version. In other words, if there are no known issues, discontinued support notices, or internationalization issues introduced in this specific restricted release, refer readers to the main RN for that information. In other words, you don't have to copy the content from the main RN to the associated sections in the restricted RN.

6. If the restricted release includes documentation, how you handle it depends on the format and how the restricted content is being delivered.
   • If the restricted content is not online (whether the release is being delivered via FTP, physical CD, or CD image), non-wiki documentation is placed in the documentation folder within the build.
     • If delivery is by physical restricted CD or CD image, you provide them to Pubs Editors for format checking (after your team has approved them) and then, once approved by Pubs Editors, Pubs Editors (Kate, in this case) adds them to the same folder as the CD Readme. Only when the restricted and approved non-online documents are in place can the restricted and approved CD Readme be frozen in XING. (All of this has to happen prior to the CD or CD image being created).
     • If delivery is by FTP (which occurs most often these days), you provide them to Pubs Editors for format checking (after your team has approved them) and then, once approved by Pubs Editors, Pubs Editors send the restricted non-online documents to Production Builds to be placed in the documentation folder of the build.
   • For restricted online content, in the Additional Information section include login credentials and the URL to the restricted (that is, set to preview) online content. Or generate a PDF of the draft restricted content for delivery with the IP, as noted above. Insert a RESTRICTED watermark (20% opacity).
7. Typically, the writer provides a draft RN to Development for review first. After Development approves the technical content, the writer provides it to QA and a Customer Care person working on your product (if known) for their technical content approval. Approval is typically sent via email for tracking purposes.
8. When the RN is approved by the PCT, the writer sends it for a Peer Review (to another writer) to approve grammatical accuracy, quality, and clarity, and then for a final Format/Content Check (to Pubs Editors) to approve the style and the format of the RN. (Note: You can also combine the next step with this one.)
9. When the restricted release is ready for release, check the Component Freeze form in XING or with your team to see if the IP is frozen and if so, that the type is Restricted.
10. Email Production Builds with the attached RN, in a format described below.
    • Copy Pubs Editors, your Project Manager, and any others that typically want to be copied for your Restricted Release Notes.
    • If the IP has not yet been frozen, alert Production Builds of that in the email. They agreed to hold onto the RN and drop it in the IP when the IP is frozen.
11. After Production Builds has added the Restricted RN to the IP, Production Builds (likely Svetlana) will email you back accordingly. If you typically reply thank you when working with folks, remove the Production Build alias from your reply because the Production Builds process uses JIRA and including the alias in your thank you email will result in reopening the associated JIRA ticket.
12. Upload your Restricted RN your product's Restricted Docs folder in MC IX Global SharePoint.

Email Examples

Format for one Restricted HTML RN in the email

Subject: Restricted RN: <component name> <7-digit version>

Hello,

The attached restricted RN is approved for inclusion in the IP for <component> <7-digit-version>. Let me know if you have any questions regarding this file.

Format for multiple Restricted HTML RNs in the email

Subject: Restricted RNs: <product name> X.Y.z

Hello,

The attached restricted RNs are approved for inclusion in their respective IPs:

• <component 1> <7 digit-version>
• <component 1> <7 digit-version>
• <component 1> <7 digit-version>

Let me know if you have any questions regarding these files.

Tip

• The writer does not generate a Release Note Notification form for a Restricted RN.
• Restricted release notes are not included on the Documentation Library DVD.
• Writers do not place restricted RNs in the Genesys Public folder in the repository or add a link to it on the product documentation landing page. You also do not add it to the Genesys Release Notes page on our documentation site. You do add it to the appropriate product folder in the Restricted Docs folder to MC IX Global > Restricted Docs in SharePoint.
• A hot fix for a restricted release is still a restricted release.