o3de / sig-release

Special Interest Group for Release (SIG Release)

Overview of SIG

This group is the coordinating group that works with all SIGs to collect and produce a release package in a cadence with a standard process. This SIG is created with chairs and maintainers from each horizontal SIG as well as dedicated members.

Goals

• Make sure releases are defined and met
• Manage schedule of releases and cadence
• Determine release naming convention
• Major goals that SIG seeks to generally achieve

Responsibilities

• Define process and explanation of what an actual release is and what is expected
• Manage and define strategies for finalizing and collecting merge requests to branch
• Define and iterate on release process and github workflow
• Define Branching strategy and pre-release schedule
• Define freeze resolution strategies
• Define late breaking changes strategies

How to Contribute SIG Release

Our team is small and help is always welcome! As a contributor you can help in one of the following ways.

• Shares any feedback or idea to improve the O3DE release process in the https://github.com/o3de/sig-release/discussions or in SIG release biweekly meeting (agenda can be read below).
• Help drives addressing feedback or idea to improve the O3DE release process, e.g. communicates with various stakeholder and facilitate discusson to address improvement. You can let the SIG release know you're happy to help certain topics by reaching out to the SIG Release Chair and Co-chair via Discord. SIG Release Chair and Co-chair Contact can be read in section "SIG Release Chair and Co-chair"

How to Engage with SIG Release

1. You can contact SIG Release via #sig-release channel in Discord
2. Join one of our bi-weekly voice call on Discord on Tuesday at 10 AM PST/PDT. You can find the next call on this calendar. Event schedules may change. For an up-to-date schedule, see the official O3DE calendar

SIG Release Chair and Co-chair

• Chair: @Tony B [Amazon]#7273 (O3DE Discord)
• Co-chair: @vincentvincent#6260 (O3DE Discord)

SIG Release - General resources

• Meeting notes from the O3DE Meetings.
• The full table of previous meetings is available here.
• SIG Charter

sig-release's Issues

Proposed SIG-Release meeting agenda for March-15-22

Meeting Details

• Date/Time: March 15, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

• Narrowed down release window to week of May 9th - May 13th, with a preference for May 12th
  • If released in May the release would be 22.05.00
  • No mandatory features for this release. What is ready will be included, what is not will wait until the following release
  • A list of 'ready' features will be available to marketing ~6 weeks before the release. We need this for internal Amazon processes as well.
  • Release notes and known issues must be ready 1 week before the release
  • Stabilization branch would need to be created week of April 1st.
  • QA must start 6 weeks before the release. Unknown as to what QA resources will be available outside of Amazon.
  • How much time will marketing need? Will this release be mentioned on the GameTech site, LF, social media, or other sites?
  • Is the proposed logo change a requirement for the release? If so, this could push out the release date.

Meeting Agenda

• Discuss proposed release timing.
  • Is the Logo change a requirement and if so, how long would marketing, UX, web development, etc need to adapt for the release?
  • What does the release sig need to take into consideration for the logo change?
• Discuss on any progress @tjmichaels has made on making previous versions of O3DE available
  • Will need to revisit this topic once web developers are hired by the LF
• Discuss any information @forhalle may have obtained concerning LF hiring web developers.
• @Ulrick28 restarting discussions around Long Term Support timeline (no progress)
  • Need to know if LTS is off the table for 2022
  • How do we support early adopter partners and customers without an LTS? Will need an alternate plan if no LTS.
• Follow up on available QA resources for our next release?
• Is there a better time/day for release sig meetings?
• @Ulrick28 (Joe B) will be stepping down from chairing the release sig starting July 1st, or the next elections, whichever comes sooner. Understanding is that the election cycle is every 6 months, which would put them sometime in June 2022.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Propose Sig-Release Meeting Agenda Topic: RTE Point Release Retrospective

We are looking for feedback on the execution of the 21.11.2 Point Release. For example:

• Were the mechanisms and tools we implemented to track the release (for example, the Point Release Project Board, and the Exception Request Project Board) sufficient in keeping everyone informed?
• Were we transparent enough in terms of the work required and the status of execution?
• Do we feel the point release process is clear enough to support non-Amazon contributors in running this process? If not, by what means do we need to bolster the process?
• Any other feedback?

Document the Point Release Process

Document the steps needed to execute a point release of O3DE so that any O3DE contributor appointed by the #sig-release can successfully lead the execution of a point release.

Acceptance Criteria:

• A runbook (a set of copy-able tasks that must be performed to execute a point release)
• A Getting Started guide outlining the role of the Release Manager, definition of a point release, best practices, a link to the runbook, etc.

Proposed SIG-Release meeting agenda for March-1-22

Meeting Details

• Date/Time: March 1, 2022 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: TBD (Joe B Out of Office)
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

• It was decided a roughly 6 month cadence makes sense given the overhead in releasing due to QA and Documentation needs. Will revisit cadence after each major release.
• Verified that the Linux Foundation is hiring Web Developers to assist with o3de.org and o3debinaries.org

Meeting Agenda

• @Ulrick28 restarting discussions around Long Term Support timeline (no progress)
  • Need to know if LTS is off the table for 2022
  • How do we support early adopter partners and customers without an LTS? Will need an alternate plan if no LTS.
• How do we handle downloading older releases of the engine?
  • Will need to revisit this topic once web developers are hired by the LF
• Right now Amazon handles all of the QA resourcing. Future releases will need assistance from outside of Amazon, particularly as O3DE grows. How will we handle QA for future releases?
• We currently do not have any available Web Developers to update the website (o3de.org and o3debinaries.org), who is responsible for staffing Web Developers? What is the plan?
  • Need an update on who/when for web developers

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed Sig-Release Meeting Agenda Topic: RTE Point Release early January

We have identified substantial workflow improvements, via the RTE program, that we would like to include in a point release in January. These improvements will not be stabilized in time for the 11/30 release, however, they add enough value that we feel a point release may be justified. I propose we discuss and then vote on supporting an early January release. This vote does not mean we will or will not have a release, it is primarily whether or not sig-release supports a potential release in January. We will take the outcome of this vote to the Steering Committee for a final yes/no decision.

RTE refers to the Rev The Engine initiative to improve common workflows. More detailed information can be found here https://github.com/o3de/sig-ui-ux/tree/main/rev-the-engine

Proposed SIG-Release meeting agenda for 2021-10-26

Meeting Details

• Date/Time: October 26, 2021 @ 05:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe Bryant
• Note Taker Terry Michaels

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

• Priority - Discuss Definition and timeline for Long Term Support (LTS) of Releases
  • LTS definition and what are the responsibilities of the sigs
  • Which release should LTS be offered for
• Release stabilization complete target
  • Current proposal is 11/19 to allow a week of testing for the final release product and to accommodate The US holiday on 11/25 (and for most 11/26 as well)
• Status Update- O3DE Stabilization and release plan, dates have already been set and agreed upon
  • Stabilization creation 10/25
  • Release created 11/30
• O3DE Release Notes, what should these notes cover?
• Review status of sig operations creation
  • Confusion between sig-operations (process and mechanisms) vs existing sig-ops repo (infrastructure operations)
• Review status of release goal communication

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

O3DE Friendly Names for Releases

Problem:
While specific release numbers are precise, they sometimes aren't friendly for discussion/communication.
(JoeB: I am expanding this issue to cover naming going forward, not just the 2111 build that has already released)
Suggestion:
O3DE names its releases with friendly names in addition to the underlying numeric release.

This issue should be considered "done" when:

1. it's decided if O3DE will have friendly names
2. a theme is decided on
3. a format for the friendly name is decided on

Please propose any themes and formats as comments to this issue. We will take these comments, vote on the suggestions, then take the top voted suggestions to the marketing committee and the tech steering committee.

Requirements for suggestions:

1. Theme needs to have longevity, covering at least 50+ major releases
2. Theme needs to not infringe on any trademarked or copyrighted material
3. Theme should be inoffensive enough to be mass marketable (reviews, publications, ads, news coverage, etc).
4. Theme must adhere to O3DE and Linux Foundation code of conduct standards as posted here https://lfprojects.org/policies/code-of-conduct/
5. Theme should not be some variation of the release versioning (example 21.11). Incorporating the release version into the friendly name can cause confusion when communicating the friendly name vs the version to the public.

SIG-Release Election Nominations 07/19 - 08/01 -- Elections 08/01 - 08/05

The chair / co-chair roles

The chair and co-chair serve equivalent roles in the governance of the SIG and are only differentiated by title in that the highest vote-getter is the chair and the second-highest is the co-chair. The chair and co-chair are expected to govern together in an effective way and split their responsibilities to make sure that the SIG operates smoothly and has the availability of a chairperson at any time.

Unless distinctly required, the term "chairperson" refers to either/both of the chair and co-chair. If a chair or co-chair is required to perform a specific responsibility for the SIG they will always be addressed by their official role title.

In particular, if both chairpersons would be unavailable during a period of time, the chair is considered to be an on-call position during this period. As the higher vote-getter they theoretically represent more of the community and should perform in that capacity under extenuating circumstances. This means that if there is an emergency requiring immediate action from the SIG, the chair will be called to perform a responsibility.

Responsibilities

• Schedule and proctor regular SIG meetings on a cadence to be determined by the SIG.
• Serve as a source of authority (and ideally wisdom) with regards to O3DE SIG area of discipline. Chairpersons are the ultimate arbiters of many standards, processes, and practices.
• Participate in the SIG Discord channel and on the GitHub Discussion forums.
• Serve as a representative of the broader O3DE community to all other SIGs, partners, the governing board, and the Linux Foundation.
• Represent the SIG to O3DE partners, the governing board, and the Linux Foundation.
• Coordinate with partners and the Linux Foundation regarding official community events.
• Represent (or select/elect representatives) to maintain relationships with all other SIGs as well as the marketing committee.
• Serve as an arbiter in SIG-related disputes.
• Coordinate releases with SIG Release.
• Assist contributors in finding resources and setting up official project or task infrastructure monitored/conducted by the SIG.
• Long-term planning and strategy for the course of the SIG area of discipline for O3DE.
• Maintain a release roadmap for the O3DE SIG area of discipline.

Additionally, at this stage of the project, the SIG chairpersons are expected to act in the Maintainer role for review and merge purposes only, due to the lack of infrastructure and available reviewer/maintainer pool.

... And potentially more. Again, this is an early stage of the project and chair responsibilities have been determined more or less ad-hoc as new requirements and situations arise. In particular the community half of this SIG has been very lacking due to no infrastructural support, and a chairperson will ideally bring some of these skills.

Nomination

Nomination may either be by a community member or self-nomination. A nominee may withdraw from the election at any time for any reason until the election starts on 08/01.

Nomination requirements

The only other nomination requirement is that the nominee agrees to be able to perform their required duties and has the availability to do so, taking into account the fact that another chairperson will always be available as a point of contact.

How to nominate

Nominations will be accepted for 2 weeks from 2022-07-19 12:00PM PT to 2022-08-01 12:00PM PT.
Nominate somebody (including yourself) by responding to this issue with:

• A statement that the nominee should be nominated for a chair position in the specific SIG holding its election. Nominees are required to provide a statement that they understand the responsibilities and requirements of the role, and promise to faithfully fulfill them and follow all contributor requirements for O3DE.
• The name under which the nominee should be addressed. Nominees are allowed to contact the election proctor to have this name changed.
• The GitHub username of the nominee (self-nominations need not include this; it's on your post.)
• Nominee's Discord username (sorry, but you must be an active Discord user if you are a chairperson.)

Election process

The election will be conducted for one week from 2022-08-01 12 00PM PT and 2022-09-05 12:00PM PT and held through an online poll. Votes will be anonymous and anyone invested in the direction of O3DE and the SIG holding the election may vote. If you choose to vote, we ask that you be familiar with the nominees.

If there is a current interim chair, they will announce the results in the Discord SIG channel as well as the SIG O3DE mailing list no later than 2022-08-08 1:00PM PT. If there is no interim chair, the executive director will announce the results utilizing the same communication channels. At that time if there is a dispute over the result or concern over vote tampering, voting information will be made public to the extent that it can be exported from the polling system and the SIG will conduct an independent audit under the guidance of a higher governing body in the foundation.

The elected chairpersons will begin serving their term on 2022-08-09 at 10:00AM PT. Tentatively SIG chairs will be elected on a yearly basis.

Proposed SIG-Release meeting agenda for Oct-19-21

Meeting Details

• Date/Time: Oct 19, 2021@ 05:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Ulrick28
• Note Taker TBD

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

Meeting Agenda

• O3DE Stabilization and release plan, dates have already been set and agreed upon
  ** Stabilization creation 10/25
  ** Release finalized 11/30
• O3DE Release Notes, what should these notes cover?
• Review status of runbook creation
  ** Identified need for stabilization runbook, release process runbook, branch creation and automation setup runbook, mechanics of allocating permissions runbook (reviewer, maintainer, etc), lfs for new branches.
  ** Have already created runbook for 'if something makes it into the repo we do not want'
  ** Need documentation on how to utilize dashboards and what each alarm and canary is for and how to respond if they alert.
• Review status of sig operations creation
• Review status of release goal communication

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Retro for O3DE Stable 21.11

This issue will serve to collect feedback on the O3DE Stable 21.11 release.
The below retro notes serve as a starting point and were compiled in the December 2021 SIG-Release meetings.
The entire O3DE community is encouraged to participate here by commenting on this issue so we can improve our releases. To make your comment useful, please start out your comment with one of the following phrases:
"Something that went well..."
"Something that didn't go well..."
"Something that we should change..."

Next Steps

• Solicit Feedback under this issue. All feedback due by Jan 19, 2022
• (optional) Depending on the feedback received, set up a specific public meeting to have further about the 21.11 release.
• For all "Things we want to change" we will create issues as needed or note how this will get addressed.
• Also post a summary to the SIG-Release channel

*****Retro is Below this line *******

Things that went well

1. Holding the release call in the channel was good.
2. We had 3-4 community members on the release call.

Things that didn't go well

1. Some issues on the call took longer like LFS, and we ended up hanging around on the call for longer than needed.
2. The release felt stressful, unpredictable
3. DCO was a constant thorn for all integrations (not just this release branch). Not everyone is signing their commits.

Things we should change

1. Would be good to get metrics from docs
2. Plan out in the open
3. Start planning earlier
4. Develop Runbooks
5. Start including Linux Foundation legal
6. At some point, have someone from the community act as release manager
7. DCO - better enforcement of DCO on individual commits. ASWF has a good DCO enforcement bot.

Proposed SIG-Release meeting agenda for April-12-22

Meeting Details

• Date/Time: April 12, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (Ulrick28)
• Note Taker Tony B

SIG Updates

What happened since the last meeting?

• Only 3 people showed up at the last meeting, with the chair and co-chair being two of them. Due to the light attendance, we decided to carry over the agenda.
• We have settled on a release date of Thursday May 12th
  • The release will be 22.05.0
  • No mandatory features for this release. What is ready will be included, what is not will wait until the following release
  • A list of 'ready' features will be available to marketing ~6 weeks before the release. We need this for internal Amazon processes as well.
  • Release notes and known issues must be ready 1 week before the release
  • Stabilization branch was created April 4th. We have 12 volunteers who will integrate stabilization/2205 to Development.
  • Internal Amazon QA has started a test pass.
  • Conversation ongoing with the Linux Foundation concerning website updates for 22.05.0
  • As per the Linux Foundation, the logo change is a requirement for the release
• Per the Technical Steering Committee, no current plans for a Long Term Support Strategy during 2022
  • Would still be useful to define what an LTS is for O3DE.

Meeting Agenda

• Until 22.05.0 is released, identify and discuss any potential blockers for the release.
  • @tonybalandiuk has been working on a feature list for this release
  • @Ulrick28 responsible for release notes, ensuring stabilization/2205 to dev integrations, and ensuring stabilization/2205 to main integration.
  • @Ulrick28 is coordinating with @yuyihsu and the Linux Foundation on website updates for the release. @yuyihsu is responsible for communicating all website needs to the Linux Foundation. We must keep any updates minimal for this pass.
  • @AMZN-Dk @Ulrick28 Track Logo changes in the editor, make sure these happen and are tested.
  • @tonybalandiuk will post and evangelize public exception process for the release.
  • @OBWANDO will create the snapshot of the feature grid to be included in the release notes.
• Discuss on any progress @tjmichaels has made on making previous versions of O3DE available. @Ulrick28 has started conversations with the Linux Foundation on resources to make the necessary website updates. We have learned that for the future, O3DE.org is responsible for website updates, not the Linux Foundation.
• Discuss updates on the hiring of website developers.
  • LF will perform a one time update for 22.05.0. Have asked us to focus on making the site evergreen. Instead of referencing a version number, instead reference 'current release' or 'latest release.
  • LF is working to contract a person to handle the website overhaul, not related to 22.05.0 release. This overhaul is on hold until a new logo is approved by legal.
• @Ulrick28 has started discussions around Long Term Support timeline
  • No LTS planned for 2022. It is recognized we should define what an LTS is during 2022.
• It has been proposed that all sigs should stagger their sig meetings. Varying the times to accommodate different time zones.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for 2022-01-04

Meeting Details

Date/Time: January 4, 2022 @ 06:00pm UTC / 10:00am PT

• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

Discuss agenda from proposed topics

• O3DE January Point Release
  • Obtain agreement on proposed Release Management Process
  • Confirm release date (currently tentative for 1/13)

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Define Release Exception Process

Once a stabilization branch is created, it is expected that no new features or breaking changes will be added to the stabilization branch. There are cases where completion may come in after the creation of stabilization, but is deemed important enough that we should consider including the feature.
We therefore need to create an easy to follow mechanism that clearly outlines who to contact, how to contact them, and what information should be included in the request for an exception. There should be an SLA attached to approval/denial response times.

Below is the suggested process for defining this mechanism:

• Gather a list of options via. a Discord discussion
• Document the options and a proposal
• Add an agenda item to the Release SIG meeting, present the proposal at the meeting, and drive to consensus

Acceptance Criteria:

• A published exception process
• Updates, as required, to the published point release process

Proposed SIG-Release meeting agenda for 2022-06-21

Meeting Details

• Date/Time: June 21, 2022 @ 5:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: @tonybalandiuk
• Note Taker @aFinchy

SIG Updates

What happened since the last meeting?

• Retro for 22.05.0 is complete. 5 TODOs were noted for the next release 22.10.0. They were added to the issue (below).
• Issue created for the 22.10.0 release #64 Marketing, SIG-UI-UX, and SIG-All have been notified to comment on the issue until Jul 1 if they have concerns with the dates.
• sig-release Roadmap is simple and basically "done" at #62

Meeting Agenda

• Review next release details #64 - re-review the dates, any comments?
• Last call for Roadmap #62
• Discuss the retro #59
• Election of chair and co-chair - issue opened at #66

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

[CANCELLED] 22.05.1 Point Release

What: Issuing an emergency point release on 2022-07-08

What caused this: the author of the widely used atomicwrites python library just deleted all old versions of the library untitaker/python-atomicwrites#61 and is apparently no longer planning to maintain it. Read more here: https://discord.com/channels/805939474655346758/805939474655346764/995068619497156738

Impact to O3DE users: Users cannot use the O3DE installer to successfully install the engine.

Why did this impact O3DE?: Atomic writes is used by pytest. Pytest is used by the installer. Pytest includes one call to atomic writes. The installer has a dependency specifically for atomic writes 1.4.0, which no longer exists. The installer dynamically downloads the dependencies of pytest and atomwrites to avoid any potential licensing issues if we were to include the source. This means, on a new machine, the installer attempts to download a dependency that no longer exists (atomicwrites 1.4.0).

1. Fix is submitted in dev

• pr HERE

2. Fix is cherry picked to main

• o3de:

3. Signed Installers are created

• [@amzn-changml] Windows
• [@amzn-changml] Linux

4. Signed Installers are tested. Note: Ensure the version number is reflected accurately upon installation.

• Windows
• Linux

5. Ensure the Build SIG uploads the installers for Windows and Linux to the below S3 buckets:

• [@amzn-changml] Windows s3://o3de-prism-prod-us-west-2/main/Latest/Windows/
• [@amzn-changml] Linux s3://o3de-prism-prod-us-west-2/main/Latest/Linux/

6. Release Tag

• [@amzn-changml] Create the release tag [22.05.1], and apply it to the following repos:
  • o3de:
  • o3de-atom-sampleviewer:
  • o3de-multiplayersample:
  • o3de-netsoaktest:
• [@amzn-changml] Begin work to add LFS binary objects to the artifacts under the new release tag, per the steps documented in this issue:

7. Documentation Updates

• Bump the version on the Windows and Linux install instructions

8. Website Updates

• O3DE.org Version number update to 22.05.1
• o3debinaries.org

9. Verification
   • [ ] Confirm the main branch has the latest code on Github
   • [@amzn-changml] Confirm the release tag is applied to main branch
   • [ ] Confirm the mainline build has begun (it should auto-start)
   • [] Confirm the version number is updated on o3debinaries.org
   • [] Confirm the Windows installer is the correct version by downloading it from o3debinaries.org
   • [] Confirm the Linux debian package is the correct version by downloading it from o3debinaries.org
   • [] Confirm the installed Windows editor shows the correct version on the splash screen
   • [] Confirm the installed Linux editor shows the correct version on the splash screen
   • [ ] Confirm the version number is updated on o3de.org (Required for Major Releases only)
   • [ ] Confirm the release notes are updated

RFC: O3DE Deprecation Strategy

Summary

O3DE needs a deprecation strategy to allow for APIs to be safely changed over time as well as entire features or systems to be removed.

Today there is no specific guidance around how to handle deprecation (current or future breaking changes).

To ensure stability and long-term support (LTS), clear definitions for how deprecation should be performed need to be created.

What is the relevance of this feature?

"Change is the only constant in life."

Heraclitus

Why is this important?

Having a policy in place for handling deprecation is incredibly important to help ensure necessary updates and changes to O3DE do not needlessly break downstream developers. Not doing this could hurt adoption and cause attrition over time.

What are the use cases?

Changes to public APIs can be manged more deliberately and guidance can be provided around how to remove larger features (how to perform this, how to communicate this etc...).

What will it do once completed?

Give developers guidance about how to change and remove features without negatively impacting customers. There should be a framework/run-book to follow for a variety of different situations to help steer developers down the right path.

Feature design description

A deprecation guide/policy will be created for developers to follow when making changes to O3DE. This guide will most likely exist on the O3DE wiki and will be a living document that grows and evolves overtime to meet the needs of O3DE and its customers.

Technical design description

Note: The technical design comes in part from PR-23 which was a first attempt at setting out guidance around how to handle deprecation.

Process Owner: sig-release

How to request changes
  - For a small change (e.g. spelling/grammar/formatting), please create a GitHub issue (or create a PR against the repo with the fix).
  - For a large change (e.g. changes to process), please create an RFC with the proposed change and reasons why (see RFC template for more details).

Deprecation Types
  - API Deprecation
  - Feature/System Deprecation

API Deprecation
  - Examples
    - Renaming a function
    - Renaming a class/EBus
    - Changing a function signature
    - Removing a function
  - Steps
    - Identify the code to be deprecated (something resembling one of the API deprecation examples outlined in the Overview)
    - Create a new GitHub issue with the name "Deprecate <Function/Type Name>"
      - Add the "kind/deprecation" label
      - In the Description, add a preliminary Release Note (what do you want to say to the customer about this change)
      - Add a milestone label for which release this deprecation will be part of
    - Add an `O3DE_DEPRECATION_NOTICE(<GHI Number>)` comment right above the API call
      - e.g.
        // O3DE_DEPRECATION_NOTICE(GHI-1234)
        AZ::Entity* CreateEditorEntity(const char* name) = 0;
    - Add an announcement to the Discord Impactful Change channel
  - (<additional guidance to follow, see https://github.com/o3de/sig-release/pull/23 for more details at time of publication>)
  - Tracking
    - sig-release can filter GHIs by date and label (kind/deprecation) to author Release Notes
  - Advice
    - Use of the `AZ_DEPRECATED` macro is not allowed when first deprecating an API
    - It is required to first use the comment identifier `O3DE_DEPRECATION_NOTICE`, and a second pass to add `AZ_DEPRECATED`
  - Note: In C++ code, `@deprecated` may be used to highlight deprecation changes in the API reference. This is not widely supported though and is not a requirement at this time

- System/Feature Deprecation
  - Create an RFC to notify the system to be deprecated
    - Include why it's being removed and identify alternatives if customers depend on X feature
    - As part of the RFC determine a deprecation schedule
    - Add who (e.g. sig responsible) to contact
    - Add an announcement to the Discord Impactful Change or relevant sig channel (when publishing the RFC and when it is either approved or rejected)
      - Include an announcement at initial proposal time and at the time of removal
    - Deprecations should also form part of the release notes and be highlighted in a features documentation
    - (<additional guidance to follow>)

- Philosophy
  - When modifying existing code that external customers rely on we should strive wherever possible to not break them when making changes.
  - If code is to be changed or removed, we should let customers know ahead of time with a reasonable notice period (approximately 1 releases (2-3 months))

- Migrations/Backwards Compatibility
  - For changes to underlying data formats, it is the developers responsibility (where possible) to provide a migration/upgrade process to allow customers to move to the new format with as little overhead as possible (e.g. Version Converters used with the Serialize Context and Object Stream in C++).
  - Note: This advice applies for changes as opposed to total removals. If it is not practical or possible to provide an automated conversion, guidance/steps should be documented to help users adjust to the change manually.
  - For more information on data migrations, please see this document `<GUIDE ON DATA MIGRATIONS - TBD>`

- Stable vs Volatile APIs
  - For new code with few users depending on it, much weaker guarantees can be made about breaking changes.
  - The source of truth for this is the SIG Feature Matrix for a given feature. If a new feature is under heavy development and no promises have yet been made about API stability, the deprecation policy does not apply. If however an API is mature and widely used, an unannounced breaking change is not acceptable. The policy of first documenting/announcing a deprecation, and then following-up with a change in future to give customers time to upgrade is required. 
  - Note: For improved visibility, owners of the SIG feature matrix should include file paths in the notes section that are explicitly excluded from the deprecation policy if the API is volatile.

What are the advantages of the feature?

We clearly define how developers should handle deprecation and set expectations from customers about the stability (in terms of change) of the engine they're using.

What are the disadvantages of the feature?

Being more careful and deliberate around deprecation does come with a cost to feature delivery. It will slow things down and potentially make making changes more difficult. This impacts internal O3DE development, and to an extent customers looking for future updates.

It is possible time may be wasted on unnecessary care given to deprecation that has minimal impact (if their are no downstream customers of a particular feature or API simply changing/deleting the code and sidestepping this whole process may be simpler/smarter).

Given the current lifetime of O3DE (less than a year after initial preview release) it may be too soon to commit to a deprecation policy (as few systems have fully settled/matured). This might be a policy that we define, but do not put into practice until churn on engine systems is a lot less.

How will this be implemented or integrated into the O3DE environment?

N/A

Are there any alternatives to this feature?

An alternative is to simply do nothing, but long term this will cause more harm than good (even factoring in the potential impact to velocity that comes with being more careful about making breaking changes).

It is likely the impact of constant breaking changes for customers will lead to frustration and them eventually leaving O3DE.

How will users learn this feature?

The guide will be highlighted on the O3DE wiki and publicized in Release Notes

Are there any open questions?

• We still need to better define the deprecation steps (see Technical design description section)
• When should we instate this policy
• How does deprecation align with releases (especially given a slow release cadence)

Proposed SIG-Release meeting agenda for July-05-22

Meeting Details

• Date/Time: July 05, 2022 @ 5:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: @Ulrick28
• Note Taker @tonybalandiuk

SIG Updates

What happened since the last meeting?

• Issue created for the 22.10.0 release #64 Marketing, SIG-UI-UX, and SIG-All have been notified to comment on the issue until Jul 1 if they have concerns with the dates.
• sig-release Roadmap is simple and basically "done" at #62
• Still determining election timing. Needs to be as soon as possible.

Meeting Agenda

• Continue review next release details #64 - re-review the dates, any comments?
• Continue discussion for Roadmap #62
  • This should always be a topic during release sig meetings as the roadmap will continually change.
  • Need to edit this doc https://docs.google.com/spreadsheets/d/1U_XAw9YJoPE3FlYeBKUz4kYjFRDS09NS3_YuZSZJ2qA/edit#gid=1112481565
• Election of chair and co-chair - issue opened at #66
  • Need a time frame that is soon as @Ulrick28 will need to step down as chair and cannot be co-chair

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

RFC for Release charter

Please read and provide feedback on our charter in this thread:

SIG Charter

This charter adheres to the Roles and Organization Management specified in .
Team information may be found in the <readme.md>

Overview of SIG

This group is the coordinating group that works with all sigs to collect and produce a release package in a cadence with a standard process. This sig is created with chairs and maintainers from each horizontal SIG as well as dedicated members.

Two concise lines explaining what this SIG does with bullet points of the major responsibilities

• Responsibility 1

Goals
Make sure releases are

Manage schedule of releases and cadence
Determine release naming convention

• Major goals that SIG seeks to generally achieve

Scope
Define process and explanation of what an actual release is and what is expected
Manage and define strategies for finalzing and collecting merge requests to branch
Define and iterate on release process and github workflow
Define Branching strategy and pre-release schedule
Define freeze resolution strategies
Define late breaking changes strategies
Define packaging and methods per platform for assets.

• Generalized overall scope of work

In scope

Responsible for confirming final state of release for any blocking issues.
Define process for triage of issues through QA/Testing, SIG bug reporting, and resolution for elements in release schedule.
Responsible for merging and producing post release hotfixes and patches

• Items that are the core responsibilities of SIG

Cross-cutting Processes

Work with QA/Testing to define and maintain minimum quality of expectations for point releases are.

Coordinate and communicate the schedule release dates and market timing, documentation and release notes publishing to docs and Governing Board (public communication)

Responsibility to define and monitor the process to determine features to be added into future release schedules along with the TSC.

Define process to resolve schedule conflicts due to issues.

Coordinate with SIGs on post-release hotfixes and patches, but not responsible for performing fixes.

Define process for coordination with out of schedule or schedule challenged dependencies across SIG feature release items.

• Items that span or require other SIGs or groups and how it relates to this SIG’s responsibilities

Out of Scope
Not responsible feature development schedules and branch management of features
Not responsible for triaging or fixing bugs
Not responsible for end user support
Not responsible for quality or capability of any specific feature
Not responsible for metrics, crash and post-release reporting, but will consult with documentation and sigs for coordination of metrics collection.
Not responsible for product feature decisions for releases, but may be consulted along with TSC, GB and SIGs.

• Items that are optional or are not the responsibility of this SIG.

SIG Links and lists:

• Joining this SIG
• Slack/Discord
• Mailing list
• Issues/PRs
• Meeting agenda & Notes

Roles and Organization Management

SIG Docs adheres to the standards for roles and organization management as specified by . This SIG opts in to updates and modifications to

Individual Contributors
All features must be submitted with a specific release value before being accepted.

Additional information not found in the sig-governance related to contributors.

Maintainers

Additional information not found in the sig-governance related to contributors

Additional responsibilities of Chairs

Additional information not found in the sig-governance related to SIG Chairs

Subproject Creation

Additional information not found in the sig-governance related to subproject creation

Deviations from sig-governance

Explicit Deviations from the sig-governance

Proposed SIG-Release meeting agenda for Jun-24-21

Meeting Details

• Date/Time: Jun 24, 2021 @ 3:00pm UTC / 8:00am PDT
• Location: Link will be posted in the #sig-release voice channel on Discord shortly before the call.
• Moderator: Joe Bryant
• Note Taker Terry Michaels

The Kickoff repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

Introductions

• Facilitator <Name, Company, Team Role>
• Participants Alphabetically - <Name, Company, Team Role> Keep it to 30 sec each

Meeting Agenda

• Discuss the scope of the SIG and the frequency with which we should meet.
• Go through the charter https://github.com/o3de/foundation/blob/main/sigs/sig-release/SIG%20Release%20Charter.md. Initial charter will be updated before meeting.
• Open topics (if time)

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussions

List any additional items below!

Proposed SIG-Release meeting agenda for 2021-12-21

Meeting Details

• Date/Time: December 21, 2021 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker: Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?
(Actions from last meeting)

• Terry reach out to Sig-Docs to have them communicate metrics about the release.
• [Done] Tony – put retro on 12/21 agenda, we will give those not present today a chance to speak first
• [Active] Tony – take friendly naming to Marketing committee https://discord.com/channels/805939474655346758/826862580618100786/920827279712612352
• [Done] Terry add to agenda for 12/21 Release SIG meeting to vote on reducing cadence to roughly every 3 months between stabilization branch cuts.

Meeting Agenda

• Confirmed seats for SIG-Release (per issue #29)
  • @amzn JoeB chair
  • @tony B co-chair
• Discuss any updates on O3DE January Point Release #27
  • Tentative date 1/13
  • Additional updates
• Vote on reducing cadence to roughly every 3 months between stabilization branch cuts.
  • Terry: provide background
  • Vote
• 12/21 release status retrospective
  • Let's discuss What went well, what didn't go well, things we should change
  • Priority to those who didn't speak in the 12/7 meeting

Discuss agenda from proposed topics

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed RFC Suggestion =Add feature/viewport label=

O3DE Suggestion RFC Template

Summary:

Please can we add a feature/viewport label for O3DE (this exists in Jira on a more granular level but would be useful to help out team transition to GHI).

What is the motivation for this suggestion?

To help filter/group viewport issues

Are there any alternatives to this suggestion?

We could create more granular viewport features (e.g. feature/viewport-interaction-model, feature/viewport-ui etc...) but it might make things simpler to group everything under feature/viewport.

Attention of @forhalle

Thanks!

Proposed SIG-Release meeting agenda for Aug-18-2021

Meeting Details

• Date/Time: Aug 18, 2021@ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Terry Michaels (tjmichaels)
• Note Taker TBD

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

• It was decided the Installer falls under sig-build purview
• It was decided the Project Manager falls under sig-content purview

Meeting Agenda

• Start discussion around next release date and when to cut the stabilization branch.
• Review charter changes
• Discuss creating a runbook for release process
• Discuss release goals and roadmap. Likely will need signoff from Steering Committee and Board.
• Labels are organizational, therefore crosscutting, who should approve? Should this be under the purview of the operations sig? Who leads the operations sig?

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for Sep 14 2021

Meeting Details

Date/Time: Sep 14, 2021@ 05:00pm UTC / 10:00am PDT
Location: Discord SIG-Release Voice Room
Moderator: Joe Bryant (Ulrick28)
Note Taker Darrin McPherson (mcphedar)

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.
SIG Updates

Meeting Agenda

Communicate the final dates for stabilization branch creation and release.
Communicate gamejam release installer date and support plan
Progress on runbooks for release process
Discuss release goals and roadmap. 
sig operations update?

Outcomes from Discussion topics

Discuss outcomes from agenda
Action Items

Create actionable items from proposed topics
Open Discussion Items

List any additional items below!

Retro for O3DE Release 22.05.0 (Feedback due by May 26, 2022)

This issue will serve to collect feedback on the O3DE 22.05.0 release.

The entire O3DE community is encouraged to participate here by commenting on this issue so we can improve our releases. To make your comment useful, please start out your comment with one of the following phrases:
"Something that went well..."
"Something that didn't go well..."
"Something that we should change..."

Next Steps

• Solicit Feedback under this issue. All feedback due by May 26, 2022
• (optional) Depending on the feedback received, set up a specific public meeting to have further discussion about the 21.11 release. 6/6 DECIDED against a separate meeting, see comment below
• For all "Things we want to change" create issues as needed or note how this will get addressed.
• Post a summary to the SIG-Release channel

Retro is Below this line

The below is an aggregate of all of the comments posted to this issue

Things that went well

• I can actually run the engine on my Intel i5 iris gpu laptop as before it just failed to start not even producing a log.
• Have not had time to do any testing apart from start-up and create a level.
• I was able to download the engine and install on my personal machine (which had 21.11 installed) and it went super-smooth with no issues (while I did have issues with a similar scenario before).
• Stabilization went quite well and changes flowing back to development didn't cause issues.
• Stabilization process and not rushing features in protected the release from destabilization, leading to more stable and less stressful release.
• Several blogs and videos timed around the release.
• Positive perception of the release 'it just works'
• Having an LF side Marketing and Community manager improved communication, particularly when compared to the 21.11.1 release.
• Regular updates on progress, schedule
• Front-loaded release note work, much smoother getting info to release team
• Integrations from stabilization to development largely went smoothly (would be great to try and include more external contributors for this in future too!)
• Triage / escalation process went well.
• Clear expectations set around quality bar for getting into stabilization.
• Docs team very responsive on docs updates for mainline.

Things that didn't go well

• Branding inconsistencies between Editor and Websites. We still need to figure out a good strategy to keep the branding consistent across all parts of the project.
• Similarly, there were inconsistencies in referencing the version number in the installer (22.5.0.0), editor splash screen (2205.0) and website (Stable 22.05).
• Branding came in at the last minute, leading to large, potentially destabilizing changes after stabilization lockdown
• Confusion around what logos needed to be changed where and with what version of the logo
• Communication about impending release was not far enough ahead, leading to questions from sig members who were surprised by the upcoming release
• Need a more consistent release notes process, as the notes came in at the last minute
• Marketing plan came in late, making it difficult for the release sig to react and/or take advantage of the plan
• Project Manager feature not working with VS 2022 out of the gate
• 11th hour issues - would be great to test these workflows earlier and more often if possible (as well as have automation to detect issues sooner rather than later).
• DCO issues for merges are still a problem, would be great to try and eliminate/fix these sooner.
• Lack of cross SIG communication about blocker/critical issues. Some issues were not raised/evaluated to see if they should be considered must fixes for release.
• Lots of scrambling around logo updates
• Lack of automation in many areas (hello asset pipeline, networking) means we are still doing expensive manual regressions.
• No clear ownership of migrating old release notes (had to go back and do a lot of a digging to see if issue x was still happening).
• No clear versioning information on docs site.

Things we should change

• Make the registry folder with the o3de_manifest.json selectable even if its a cmake option. I understand it is not as straightforward as some might think but have seen this requested by a few people.
  • This is related to bug o3de/o3de#2078 - added a comment there.
• Maybe make it easier overall to handle multiple engines.
  • This is a current feature request: o3de/o3de#3536
• Determine a release manager earlier (at least 90 days ahead of release)
  • noted as a todo under #64
• Determine release date earlier (at least 90 days ahead of release)
  • as of 6/14 the proposed release date has been posted under #64
• Document release notes process and timeline
  • noted as a todo under #64
• Coordinate with Marketing Sig earlier. Set deadlines!
  • noted as a todo under #64
• Clearer notification of timeline for release builds. Set date early so we can plan around disruption. Set clear dates up front with SIGs around testing.
  • noted as a todo under #64
• More regression / adhoc testing early in process. Mentioned to sig-testing in Discord. https://discord.com/channels/805939474655346758/816043958341861376/988934730516955226
• Release notes should mostly be driven off issues, but issues can change/reopen/close post release. Not sure if we still have clear process.
  • noted as a todo under #64
• Weekly SIG triage cadence does not gel with limited window for release builds. May need SIG of SIGs daily triage or clearer mechanisms for raising and escalating issues. Waiting a week for a SIG to respond on a critical which should be launching blocking seems risky.
  • noted as a todo under #64

22.05.0 Known Issues List

Please add a comment to this issue with any known issues you would like called out for the 22.05.0 list which is here: https://github.com/o3de/sig-release/blob/main/releases/22.05.0/O3DE%2022050%20Release%20Notes.md

Define stabilization to development merging process

Summary:

The project should detail and implement a public process to enact periodic merges from the stabilization branch to the development branch during the stabilization process.

Note that such a process was already successfully enacted during all O3DE releases - this suggestion is to make this process accessible from any contributor that wants to volunteer their time.

What is the motivation for this suggestion?

A gitflow process to periodically merge bugfixes back to development during the stabilization process is beneficial to contributors in multiple ways:

• Enables developers working on bugfixes to only target a single branch (stabilization), with the knowledge that their bugfixes will reach the cutting-edge development branch with no extra effort on their part;
• Guarantees that all stabilization bugfixes are merged together, and not piecemeal (which adds the risk of individual fixes being cherrypicked out of order causing merge issues, or being completely forgotten).

In all releases so far, the gitflow process was run by a group of developers that volunteered that time to provide two merges a week for the duration of the stabilization period. All developers were from the Game Engine & Developer Services team at Amazon, and coordinated the effort in a private chat.

This suggestion aims to

• Move this process to the O3DE discord and make it public, so that any contributor can volunteer their time to help;
• Generate a merging process document detailing the process clearly for contributors.

Suggestion design description:

Since this process has been run multiple times internally already, a document exists detailing the guidelines. The aim should be to update this existing document to make it public:

• Define requirements for volunteers contributing to the process (seniority? role?);
• Detail the steps to follow (which branches to sync, the commands to use...);
• Specify how to verify the submission (which reviewers to add in each PR, how to handle DCO issues).

If deemed necessary, incentives for volunteers participating in the process could be added?

What are the advantages of the suggestion?

Making this process public contributes to the health of the project and enables any contributor to run a release successfully.

What are the disadvantages of the suggestion?

Can't think of one :)

Feature Request: Process for creating branches for downstream projects when new branches made on o3de/o3de

Is your feature request related to a problem? Please describe.
Have user confusion when downstream projects do not have tracking branches for the main o3de/o3de branches. Case in point is the recent stabilization/201111RTE branch

In Sig-network developers were confused as to which branch of MultiplayerSample they should use against the stabilization/201111RTE o3de branch. See o3de/o3de-multiplayersample#101 plus conversations in sig-network.

Other downstream repros:

• ASV: https://github.com/o3de/o3de-atom-sampleviewer/branches (no 201111RTE branch, but has 201110 stabilization branch)
• Netsoak test: https://github.com/o3de/o3de-netsoaktest

Describe the solution you'd like
A clear mechanism to convey to downstream O3DE projects that a new main branch has been open.

• Clear ownership of downstream 'o3de' sample projects so owners can be reached
• Commitment for all active downstream projects to have tracking branches against main o3de repro

Describe alternatives you've considered

• Automatically creating tracking branches in downstream projects (may not be possible as SIG-release does not own these project and they are in different stages of readiness)

Additional context
Add any other context or screenshots about the feature request here.

Proposed SIG-Release meeting agenda for February-15-2022

Meeting Details

• Date/Time: February 15, 2022 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (@Ulrick28)
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

• O3DE Version convention agreed upon by the TSC
  • All future releases will use the yy.mm.version format
  • Friendly naming convention has been de-prioritized by the marketing committee

Meeting Agenda

• Release Cadence still up for discussion
  • @Ulrick28 (Joe Bryant) to post data (QA, Docs, Website, Legal, Marketing lead times) for the next TSC meeting
• @Ulrick28 restarting discussions around Long Term Support timeline
  • Need to know if LTS is off the table for 2022
  • How do we support early adopter partners and customers without an LTS? Will need an alternate plan if no LTS.
• How do we handle downloading older releases of the engine?
  • Still no plan at the moment
• Right now Amazon handles all of the QA resourcing. Future releases will need assistance from outside of Amazon, particularly as O3DE grows. How will we handle QA for future releases?
• We currently do not have any available Web Developers to update the website (o3de.org and o3debinaries.org), who is responsible for staffing Web Developers? What is the plan?
  • Need verification that the Linux Foundation is indeed hiring Web Developers.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for May-24-22

Meeting Details

• Date/Time: May 24, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (Ulrick28)
• Note Taker Tony B

SIG Updates

What happened since the last meeting?

• O3DE 22.05.0 was released!

Meeting Agenda

• Scheduling for next release
  • Thoughts are to time around O3DECon which is Oct 18-19.
  • We should schedule for at least a week earlier to allow room for slip
• O3DE Triage owner needs to step down due to schedule conflicts.
  • Need volunteers to continue the meeting if it is deemed something that should be continued. Unsure as to which sig (if any) owns the process
• TSC has asked Release sig to own working with sigs to publish a roadmap. (ongoing discussion)
• Reminder, will start posting for chair nominations early June, for position to be filled by July 1st. Current Chair (JoeB/Ulrick28) is stepping down due to availability conflicts.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for Nov-23-21

Meeting Details

• Date/Time: November 23, 2021 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe Bryant
• Note Taker Terry Michaels

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

• 11/30 release status update
  • Stabilization locked. Only testing and Blocking issues only
  • Stabilization copy to main on track for 11/30
  • Installer, marketing, documentation, and social media release scheduled for 12/2 to coincide with re:invent schedule
• O3DE Release Notes creation and communication update
  • Draft release notes created. Documentation currently polishing.
• RTE Point release #27
• Discuss any updates for Definition of Long Term Support (LTS) of Releases
• Future release cadence?
  • Currently scheduled for ~6 months
• When should we hold elections?
  • No update as release has been priority
• Friendly Names for releases?
  • example 2205.1 Silly Squirrel release (we need a naming theme!)
• Continued reminder: Please use @sig-release on Discord when needing to communicate with interested sig-release members. Do NOT use @here.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for June-07-22

Meeting Details

• Date/Time: Jun 07, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (Ulrick28)
• Note Taker Tony B

SIG Updates

What happened since the last meeting?

• Discussed proposed release date with Linux Foundation and the TSC. No concerns over the release date.
• We are proposing to the following schedule:
  8/29 Create stabilization branch(no features allowed past this date)
  Bug Fixes allowed until 9/27
  9/27 "Code Freeze" (bug fixes only allowed with exception after this date)
  10/11 Release tasks are done. Binaries posted, code merged, etc.
  10/13 marketing announcement
• Discussed proposed release date with Walk the Engine Efforts, awaiting feedback
• Need to Discuss release plan with Marketing Committee
• Walked back from 10/11 release tasks done, we will need to decide any shifts in dates by June 30th, in order to guarantee 90 days before stabilization lock.
• Roadmap discussions are ongoing. Nicole from the LF appears to be taking point. Chairs and Co-Chairs are asking for templates.

Meeting Agenda

• Discuss current next release plan
  • 8/29 Create stabilization branch(no features allowed past this date)
  • Bug Fixes allowed until 9/27
  • 9/27 "Code Freeze" (bug fixes only allowed with exception after this date)
  • 10/11 Release tasks are done. Binaries posted, code merged, etc.
  • 10/13 marketing announcement
• TSC has asked Release sig to own working with sigs to publish a roadmap. Roadmap discussions are ongoing. Nicole from the LF appears to be taking point. Chairs and Co-Chairs are asking for templates.
• Reminder, will start posting for chair nominations early June, for position to be filled by July 1st. When should we start the voting?
• @Ulrick28 (current Chair) will be on PTO from Friday Jun 10th until Sunday June 26th. @tonybalandiuk will be the primary contact for any sig-release business during this time.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for Sept-28-21

Meeting Details

• Date/Time: Sept 28, 2021@ 05:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Ulrick28
• Note Taker TBD

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

Meeting Agenda

• O3DE Game Jam communication plan
• Review status of runbook creation
• Review status of sig operations creation
• Review status of release goal communication

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for May-10-22

Meeting Details

• Date/Time: May 10, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (Ulrick28)
• Note Taker Tony B

SIG Updates

What happened since the last meeting?

• Continued work to stabilize the 22.05.0 release via https://github.com/o3de/o3de/tree/stabilization/2205
• Stabilization PR submission exception process defined https://github.com/o3de/o3de/projects
• Feature list created in the sig-release repo.
• Stabilization is locked and we are green for 5/12 release.
  • Release Notes created
  • Docs are prepped
  • Stabilization prepped for copy to main
  • Feature grid added to release notes
  • Release Dry run was successful
  • Marketing verified plans for after the release
  • Testing is complete
  • LF to own updating of website, Amazon to own updating of binaries download page

Meeting Agenda

• Until 22.05.0 is released, identify and discuss any potential blockers for the release.
  • Logo has been updated
  • 0 blockers/criticals for the release
• TSC has asked Release sig to own working with sigs to publish a roadmap.

Outcomes from Discussion topics

Discuss outcomes from agenda

• Add roadmap discussion as a regular topic for sig-release meetings.

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for January-18-2022

Meeting Details

• Date/Time: January 18, 2022 @06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

• Blog will post one week after the point release
• Meeting to discuss remaining dependencies for release scheduled for Tuesday January 18th, 2022 @ 2:30 PM PT.

Meeting Agenda

Discuss agenda from proposed topics

• Update on progress of point release
• Determination of release cadence?
  • No determination as of yet, discuss steps to quicken determination of cadence
  • If no determination is made for the near term (need to define date), suggestion to default to previously agreed 6 month cadence
• Partners and users are expressing frustration with the stability of Development branch
  • Development branch will be inherently unstable due to the Development containing day to day updates of code that has not gone through a stabilization process
  • Development branch stability varies wildly from day to day, with some submissions breaking basic functionality such as ability to add gems to a project, ability to process assets, or ability to utilize common functions in the editor.
• GDC is coming soon (March 21-25), should coordinate with marketing committee, TSC, and Linux Foundation on any plans

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for March-29-22

Meeting Details

• Date/Time: March 29, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources. If you wish to add to the agenda, please comment on this issue.

SIG Updates

What happened since the last meeting?

• We have settled on a release date of Thursday May 12th
  • The release will be 22.05.0
  • No mandatory features for this release. What is ready will be included, what is not will wait until the following release
  • A list of 'ready' features will be available to marketing ~6 weeks before the release. We need this for internal Amazon processes as well.
  • Release notes and known issues must be ready 1 week before the release
  • Stabilization branch will be created April 4th. @Ulrick28 is currently identifying who will create the branch and an integration cadence.
  • QA will start when branch is created. Still unknown as to what QA resources will be available outside of Amazon.
  • How much time will marketing need? Will this release be mentioned on the GameTech site, LF, social media, or other sites?
  • As per the Linux Foundation, the logo change is not a requirement for the release
• Per the Technical Steering Committee, no current plans for a Long Term Support Strategy during 2022
  • Would still be useful to define what an LTS is for O3DE.

Meeting Agenda

• Discuss release timing. Any disagreement on the date? Thoughts on the release?
  • @tonybalandiuk has been working on a feature list for this release
• Discuss on any progress @tjmichaels has made on making previous versions of O3DE available
• Discuss any information @forhalle may have obtained concerning LF hiring web developers.
• @Ulrick28 restarting discussions around Long Term Support timeline
  • Changing discussion from 2022 LTS to defining what an LTS is for O3DE
• Is there a better time/day for release sig meetings?

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for January-04-2022

Meeting Details

• Date/Time: January 04, 2022 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker: Tony B

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?
(Actions from last meeting)

• Confirmed seats for SIG-Release (per issue SIG-Release Chair/Co-Chair Nominations 12/1 - 12/8 -- Elections 12/8 - 12/15 #29)
  @amzn JoeB chair @tony B co-chair
• Discussed moving point release date to end of January (was January 13th, 2022)
  • After discussions a new tentative release date set for January 27th, 2022
• Issue created for determining point release mechanisms #35
  -> Action - Joe B create an issue for versioning
• Discussed release cadence, to be brought up with the Technical Steering Committee
  • Current thought is to reduce from 6 months to 3 months
  • Meeting attendees voted to reduce release cadence to 3 months, taking this vote to the Technical Steering Committee for discussion.
• It was determined we need an exception process for stabilization branches. This process would allow a sig to request an exception to include a feature or fix that would normally not qualify for inclusion in a stabilization branch, but is deemed beneficial for the release. @forhalle to follow up.

Meeting Agenda

• Determining point release mechanisms #35

• Vote on point release date, proposed is Thursday January 27th, 2021.

• Any further additions to post mortem. Should we have a dedicated post mortem meeting?

  • See Open Discussion items for current post mortem notes.

Discuss agenda from proposed topics

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

12/21 release status retrospective
Things that went well

• SanB – it went well overall. Call in the channel was good.
• Terry – we had 3-4 community members on the release call. Would be good to plan in the public

Things that didn't go well

• Some issues on the call took longer like LFS, we ended up hanging around on the call.
• Release felt stressful, unpredictable
• DCO was a constant thorn for all integrations (not just this release branch). Not everyone is signing their commits.

Things we want to change

• Would be good to get metrics from docs
• Plan out in the open
• Start planning earlier
• Runbooks
• Start including Linux Foundation legal
• Have someone from the community act as release manager
• DCO - better enforcement of DCO on individual commits. ASWF has a good DCO enforcement bot.
• For Jan, set up a specific public meeting to have a larger retro about the 21.11 release.

List any additional items below!

Proposed SIG-Release meeting agenda for February-01-2022

Meeting Details

• Date/Time: February 1, 2022 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B
• Note Taker Tony B , Terry as backup

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

• O3DE 2111.2 released
  • Launch call occurred Thursday January 27th, 10am PT
• Discuss friendly naming Marketing Committee proposal
  • #39
• Discuss any updates on determining release cadence
  • We are finding that 3 month releases may introduce too much overhead and put O3DE in a perpetual release mode. Marketing, QA, and should weigh in.
  • Between now and the next release, we need time to coordinate new plans for QA and Website updates.
  • What factors determine a release date?
• How do we handle downloading older releases of the engine?
• Right now Amazon handles all of the QA resourcing, those resources are declining. How will we handle QA for future releases?
• We currently do not have any available Web Developers to update the website (o3de.org and o3debinaries.org), who is responsible for staffing Web Developers?

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Document the Major Release Process

Document the steps needed to execute a major release of O3DE so that any O3DE contributor appointed by the #sig-release can successfully lead the execution of a major release.

Consider the differences between the work required for a point release (#44) and a major release.

Acceptance Criteria:

• A runbook (a set of copy-able tasks that must be performed to execute a point release)
  A Getting Started guide outlining the role of the Release Manager, definition of a major release, best practices, a link to the runbook, etc.

O3DE Release 22.10.0 Key Information

This issue is a single destination for all things related to the O3DE 22.10.0 Release. This issue will be updated as information changes. We will use this issue to surface questions and answer them so the entire community is aware of what to expect for the 22.10.0 release.

O3DE 22.10.0 About this Release
O3DE 22.10.0 will be the second major release of O3DE in 2022. The previous release was the 22.05.0 major release (May 13, 2022). The release will contain all of the features in the dev branch as of August 29, 2022 12:00 Pacific time. This release is intended to coincide with O3DE's Annual O3DCon October 18-19, 2022.

Release Managers
Release Manager: @tonybalandiuk (Discord @tony B [Amazon]#7273)
Co-Release Manager: @vincent6767 (Discord @vincentvinvent )

Release Project Board
https://github.com/o3de/o3de/projects/18

Feature List
https://github.com/o3de/sig-release/blob/main/releases/22.10.0/22100%20feature%20list.md

Release Notes
Coming September 2022

Stabilization Branch
Coming August 29. 2022

Stabilization Bug Reporting
In the stabilization branch, any bugs found should get the "Release/2210" milestone applied.

Bug Tracking
O3DE main repo - Bugs are being tracked with the Release/2210 Milestone.
Atom Sample Viewer repo - TBD

Release Schedule with Exception Process for Submitting Code to the Stabilization Branch
As documented in the below table, submissions to the stabilization branch will be subject to an Exception Process, described here in the description for project "stabilization/2210 - Exception Requests"

Date	Description	Bug Fixes Allowed in Stabilization Branch	New Features Allowed in Stabilization Branch
Jul 1, 2022	Feedback period closed. No SIGs raised any concerns with release schedule	N/A	N/A
Jul 7, 2022	Marketing committee confirmed ok with proposed release schedule	N/A	N/A
Jul 12, 2022	Release managers posted, empty project board set up.	N/A	N/A
Aug 29, 2022 10am Pacific	Stabilization Branch created.	N/A	N/A
Aug 30, 2022	(Docs) Stabilization branch created	N/A	N/A
Aug 29 through Sep 26, 2022	Stabilization Period	Yes	Yes via, exception process.
Sep 27, 2022	Code Freeze on Major Bugs and below	Beginning this date, only Blocker and Critical bugs are allowed without the exception process.	No
Sep 30	(Docs) Versioned API reference generation	N/A	N/A
Sep 30, 2022	(Docs) Release Notes Finalized (features + known issues)	N/A	N/A
Sep 30, 2022	Code Freeze on Critical Bugs and below	Beginning this date, only Blocker bugs are allowed via the exception process.	No
Sep 30 through Oct 5, 2022	QA Final Pass	Beginning this date, only Blocker bugs are allowed via the exception process, with risk of delaying the release.	No
Oct 5, 2022	Release considered "stable", all blocker/critical issues are resolved.	No	No
Oct 11, 2022	Release tasks are done. Binaries posted, code merged, etc.	No	No
Oct 13, 2022	22.10.0 Release Marketing Announcement	No	No

Proposed SIG-Release meeting agenda for April-26-22

Meeting Details

• Date/Time: April 26, 2022 @ 05:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe B (Ulrick28)
• Note Taker Tony B

SIG Updates

What happened since the last meeting?

• Continued work to stabilize the 22.05.0 release via https://github.com/o3de/o3de/tree/stabilization/2205
• Stabilization PR submission exception process defined https://github.com/o3de/o3de/projects
• Feature list created in the sig-release repo.

Meeting Agenda

• Until 22.05.0 is released, identify and discuss any potential blockers for the release.
  • @tonybalandiuk has been working on a feature list for this release.
  • @Ulrick28 release notes started, will link to @tonybalandiuk feature list.
  • @Ulrick28 to reach out to @OBWANDO for latest feature grid.
  • We currently have 15 blocking/Critical issues for 22.05.0 release. Sigs are working to address these before the EOD 4/28 code lockdown. Note that issues can be resolved after the lockdown, PR's to stabilization/2205 will just require an exception approval from the sigs
• New logo has been decided on. Sig-content, sig-ui-ux are working on editor implementation and coordinating with o3de.org on website implementation.
• Website updates will be minimal for the 22.05.0 release. This is due to a full website overhaul that is pending. LF has identified a contractor for both the minimal update (22.05.0) and the website overhaul.
• Making multiple versions of O3DE available will be addressed as a part of the website overhaul
• (No Update) Discuss updates on the hiring of website developers.
  • We (the sigs) will need to work with O3DE.org to contract a dedicated web developer.
• It has been proposed that all sigs should stagger their sig meetings. Varying the times to accommodate different time zones. @Ulrick28 to own this

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

SIG-Release Chair/Co-Chair Nominations 12/1 - 12/8 -- Elections 12/8 - 12/15

SIG chair / co-chair elections for 2022

Since the inception of O3DE, each SIG chair has been staffed as an interim position. It's time to hold some official elections, following some of the proposed guidance but with our own process due to the holiday season and in order to expedite the elections into next year.

The chair / co-chair roles

The chair and co-chair serve equivalent roles in the governance of the SIG and are only differentiated by title in that the highest vote-getter is the chair and the second-highest is the co-chair. The chair and co-chair are expected to govern together in an effective way and split their responsibilities to make sure that the SIG operates smoothly and has the availability of a chairperson at any time.

Unless distinctly required, the term "chairperson" refers to either/both of the chair and co-chair. If a chair or co-chair is required to perform a specific responsibility for the SIG they will always be addressed by their official role title.

In particular, if both chairpersons would be unavailable during a period of time, the chair is considered to be an on-call position during this period. As the higher vote-getter they theoretically represent more of the community and should perform in that capacity under extenuating circumstances. This means that if there is an emergency requiring immediate action from the SIG, the chair will be called to perform a responsibility.

Responsibilities

• Schedule and proctor regular SIG meetings on a cadence to be determined by the SIG.
• Serve as a source of authority (and ideally wisdom) with regards to O3DE SIG area of discipline. Chairpersons are the ultimate arbiters of many standards, processes, and practices.
• Participate in the SIG Discord channel and on the GitHub Discussion forums.
• Serve as a representative of the broader O3DE community to all other SIGs, partners, the governing board, and the Linux Foundation.
• Represent the SIG to O3DE partners, the governing board, and the Linux Foundation.
• Coordinate with partners and the Linux Foundation regarding official community events.
• Represent (or select/elect representatives) to maintain relationships with all other SIGs as well as the marketing committee.
• Serve as an arbiter in SIG-related disputes.
• Coordinate releases with SIG Release.
• Assist contributors in finding resources and setting up official project or task infrastructure monitored/conducted by the SIG.
• Long-term planning and strategy for the course of the SIG area of discipline for O3DE.
• Maintain a release roadmap for the O3DE SIG area of discipline.

Additionally, at this stage of the project, the SIG chairpersons are expected to act in the Maintainer role for review and merge purposes only, due to the lack of infrastructure and available reviewer/maintainer pool.

... And potentially more. Again, this is an early stage of the project and chair responsibilities have been determined more or less ad-hoc as new requirements and situations arise. In particular the community half of this SIG has been very lacking due to no infrastructural support, and a chairperson will ideally bring some of these skills.

Nomination

Nomination may either be by a community member or self-nomination. A nominee may withdraw from the election at any time for any reason until the election starts on 12/3.

Nomination requirements

For this election, nominees are required to have at minimum two merged submissions to http://github.com/o3de/o3de (must be accepted by 2022-01-31). This is to justify any temporary promotion to Maintainer as required by this term as chairperson. Submissions may be in-flight as of the nomination deadline (2021-12-08 12PM PT), but the nominee must meet the 2-merge requirement by the end of the election or they will be removed from the results.

Any elected chairperson who does not currently meet the Maintainer status will be required to work with contributors from the SIG to produce an appropriate number of accepted submissions by January 31, 2022 or they will be removed and another election will be held.

The only other nomination requirement is that the nominee agrees to be able to perform their required duties and has the availability to do so, taking into account the fact that another chairperson will always be available as a point of contact.

How to nominate

Nominations will be accepted for 1 week from 2021-12-01 12:00PM PT to 2021-12-08 12:00PM PT.
Nominate somebody (including yourself) by responding to this issue with:

• A statement that the nominee should be nominated for a chair position in the specific SIG holding its election. Nominees are required to provide a statement that they understand the responsibilities and requirements of the role, and promise to faithfully fulfill them and follow all contributor requirements for O3DE.
• The name under which the nominee should be addressed. Nominees are allowed to contact the election proctor to have this name changed.
• The GitHub username of the nominee (self-nominations need not include this; it's on your post.)
• Nominee's Discord username (sorry, but you must be an active Discord user if you are a chairperson.)

Election process

The election will be conducted for one week from 2021-12-08 12:00PM PT and 2021-12-15 12:00PM PT and held through an online poll. Votes will be anonymous and anyone invested in the direction of O3DE and the SIG holding the election may vote. If you choose to vote, we ask that you be familiar with the nominees.

If there is a current interim chair, they will announce the results in the Discord sig channel as well as the SIG O3DE mailing list no later than 2021-12-17 1:00PM PT. If there is no interim chair, the executive director will announce the results utilizing the same communication channels. At that time if there is a dispute over the result or concern over vote tampering, voting information will be made public to the extent that it can be exported from the polling system and the SIG will conduct an independent audit under the guidance of a higher governing body in the foundation.

The elected chairpersons will begin serving their term on 2022-01-01 at 12AM PT. Tentatively SIG chairs will be elected on a yearly basis. If you have concerns about wanting to replace chairs earlier, please discuss in the request for feedback on Governance.

Proposed Sig-Release Meeting Agenda Topic: Release Management Mechanisms

I propose we discuss and then vote on a standard mechanisms for managing the O3DE release process. The proposed mechanisms are below.

In Scope for this Proposal

• The tools and communication channels to be used while executing the release process.

Out of Scope for this Proposal

• The specific tasks to be executed during the O3DE release process.
• The roles and responsibilities of those involved in the release process.

Tenets

The release mechanisms should be:

• Publicly accessible so that the release can be managed and executed by the O3DE community.
• Consistent and usable across both major and point releases.
• Integrated into existing SIG processes (e.g. Issue triage, Discord communication, etc.).
• Adaptable to account for varying levels of SIG maturity (e.g. some SIGs have already established recurring meeting agendas, issue triage, etc.; where as other SIGs are just beginning to establish such processes).

Proposal

1. Manage the release tasks through a set of GHI issues collected into a Project (example).
   1.1 Host a set of tasks in the SIG Release Repo which can be cloned (method TBD) into the O3DE Repo at the start of each release.
   1.2 Use the cloned tasks in the O3DE Repo (not the original tasks in the SIG Release Repo) to manage each release, leveraging existing triage mechanisms, and enabling involved SIGs to manage their release work alongside all other O3DE work.
   1.3 Include a post-release template task for the RM to refine the template tasks in the SIG Release Repo with any lessons learned.

2. Host recurring release-specific status meetings via. the Discord #sig-release special interest group voice channel (via. an invite on the O3DE Calendar).
   2.1 "Require" attendance for key resources involved in the release (e.g. QA, Docs, Product, etc.).
   2.2 Increase the frequency of the meetings as we near the release date (e.g. twice weekly 4 weeks prior to release, daily 2 weeks prior to the release, and a ~1/2 day meeting the day of release).

3. Use Discord for all communication
   1.1 Utilize the Discord #sig-release channel for the majority of questions and status updates pertaining to the release. Multiple threads can be used (vs. consolidating all release conversations into a single thread for each release).
   1.2 Refrain from utilizing individual Discord SIG channels (e.g. #sig-testing, #sig-build, etc.) as much as possible - the majority of conversations should occur in #sig-release to keep all involved up to date.

[DRAFT] SIG-Release Chair/Co-Chair Nominations 6/21 - 6/28 -- Elections 6/28 - 7/5

SIG chair / co-chair elections for 2022 (July through December)

See proposed guidance for more context about the election process.
Also some proposed guidance here: https://docs.google.com/document/d/1d7lAp351d3s5KHZOm3e7ZHyeeMDfEM4W0BoEej5JybM/edit

The chair / co-chair roles

The chair and co-chair serve equivalent roles in the governance of the SIG and are only differentiated by title in that the highest vote-getter is the chair and the second-highest is the co-chair. The chair and co-chair are expected to govern together in an effective way and split their responsibilities to make sure that the SIG operates smoothly and has the availability of a chairperson at any time.

Unless distinctly required, the term "chairperson" refers to either/both of the chair and co-chair. If a chair or co-chair is required to perform a specific responsibility for the SIG they will always be addressed by their official role title.

In particular, if both chairpersons would be unavailable during a period of time, the chair is considered to be an on-call position during this period. As the higher vote-getter they theoretically represent more of the community and should perform in that capacity under extenuating circumstances. This means that if there is an emergency requiring immediate action from the SIG, the chair will be called to perform a responsibility.

Responsibilities

• Schedule and proctor regular SIG meetings on a cadence to be determined by the SIG.
• Serve as a source of authority (and ideally wisdom) with regards to O3DE SIG area of discipline. Chairpersons are the ultimate arbiters of many standards, processes, and practices.
• Participate in the SIG Discord channel and on the GitHub Discussion forums.
• Serve as a representative of the broader O3DE community to all other SIGs, partners, the governing board, and the Linux Foundation.
• Represent the SIG to O3DE partners, the governing board, and the Linux Foundation.
• Coordinate with partners and the Linux Foundation regarding official community events.
• Represent (or select/elect representatives) to maintain relationships with all other SIGs as well as the marketing committee.
• Serve as an arbiter in SIG-related disputes.
• Coordinate releases with SIG Release.
• Assist contributors in finding resources and setting up official project or task infrastructure monitored/conducted by the SIG.
• Long-term planning and strategy for the course of the SIG area of discipline for O3DE.
• Maintain a release roadmap for the O3DE SIG area of discipline.

Additionally, at this stage of the project, the SIG chairpersons are expected to act in the Maintainer role for review and merge purposes only, due to the lack of infrastructure and available reviewer/maintainer pool.

... And potentially more. Again, this is an early stage of the project and chair responsibilities have been determined more or less ad-hoc as new requirements and situations arise. In particular the community half of this SIG has been very lacking due to no infrastructural support, and a chairperson will ideally bring some of these skills.

Nomination

Nomination may either be by a community member or self-nomination. A nominee may withdraw from the election at any time for any reason until the election starts on 6/28.

Nomination requirements

For this election, nominees are required to have at minimum two merged submissions to http://github.com/o3de/o3de (must be accepted by 2022-01-31). This is to justify any temporary promotion to Maintainer as required by this term as chairperson. Submissions may be in-flight as of the nomination deadline (2021-12-08 12PM PT), but the nominee must meet the 2-merge requirement by the end of the election or they will be removed from the results.

Any elected chairperson who does not currently meet the Maintainer status will be required to work with contributors from the SIG to produce an appropriate number of accepted submissions by January 31, 2022 or they will be removed and another election will be held.

The only other nomination requirement is that the nominee agrees to be able to perform their required duties and has the availability to do so, taking into account the fact that another chairperson will always be available as a point of contact.

How to nominate

Nominations will be accepted for 1 week from 2022-6-21 12:00PM PT to 2022-6-28 12:00PM PT.
Nominate somebody (including yourself) by responding to this issue with:

• A statement that the nominee should be nominated for a chair position in the specific SIG holding its election. Nominees are required to provide a statement that they understand the responsibilities and requirements of the role, and promise to faithfully fulfill them and follow all contributor requirements for O3DE.
• The name under which the nominee should be addressed. Nominees are allowed to contact the election proctor to have this name changed.
• The GitHub username of the nominee (self-nominations need not include this; it's on your post.)
• Nominee's Discord username (sorry, but you must be an active Discord user if you are a chairperson.)

Election process

The election will be conducted for one week from 2026-6-28 12:00PM PT until 2022-7-5 12:00PM PT and held through an online poll. Votes will be anonymous and anyone invested in the direction of O3DE and the SIG holding the election may vote. If you choose to vote, we ask that you be familiar with the nominees.

If there is a current interim chair, they will announce the results in the Discord sig channel as well as the SIG O3DE mailing list no later than 2022-7-7 1:00PM PT. If there is no interim chair, the executive director will announce the results utilizing the same communication channels. At that time if there is a dispute over the result or concern over vote tampering, voting information will be made public to the extent that it can be exported from the polling system and the SIG will conduct an independent audit under the guidance of a higher governing body in the foundation.

The elected chairpersons will begin serving their term on 2022-7-12 at 12AM PT. Tentatively SIG chairs will be elected on a 6-month. If you have concerns about wanting to replace chairs earlier, please discuss in the request for feedback on Governance.

Proposed SIG-Release meeting agenda for November-11-21

Meeting Details

• Date/Time: November 11, 2021 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Joe Bryant
• Note Taker Terry Michaels

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

• Release stabilization complete target (update)
  • Current proposal is 11/19 to allow a week of testing for the final release product and to accommodate The US holiday on 11/25 (and for most 11/26 as well)
• Status Update- O3DE Stabilization and release plan, dates have already been set and agreed upon (reiteration of plan)
  • Stabilization creation 10/25
  • Release created 11/30
• O3DE Release Notes creation and communication update
• Discuss any updates for Definition of Long Term Support (LTS) of Releases
• Future release cadence?
• When should we hold elections?
• Please use @sig-release on Discord when needing to communicate with interested sig-release members. Do NOT use @here.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for Aug-03-21

Meeting Details

• Date/Time: Aug 3rd, 2021 @ 3:00pm UTC / 8:00am PDT
• Location: Link will be posted in the #sig-release voice channel on Discord shortly before the call.
• Moderator: Joe Bryant
• Note Taker Joe Bryant

The Kickoff repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

Introductions

• Facilitator <Name, Company, Team Role>
• Participants Alphabetically - <Name, Company, Team Role> Keep it to 30 sec each

Meeting Agenda

• Second kickoff meeting due to low attendance of first meeting
• Discuss the scope of the SIG and the frequency with which we should meet.
• Go through the charter https://github.com/o3de/foundation/blob/main/sigs/sig-release/SIG%20Release%20Charter.md. Initial charter will be updated before meeting.
• Open topics (if time)

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussions

List any additional items below!

Proposed SIG-Release meeting agenda for July-19-22

Meeting Details

• Date/Time: July 19, 2022 @ 5:00pm UTC / 10:00am PDT
• Location: Discord SIG-Release Voice Room
• Moderator: @Ulrick28
• Note Taker @tonybalandiuk

SIG Updates

What happened since the last meeting?

• Question was raised by the tsc concerning communicating any sort of date in the roadmap. Open source projects do not communicate feature time frames due to the volunteer nature of development.

Meeting Agenda

• Continue review next release details #64 - re-review the dates, any comments?
• Continue discussion for Roadmap #62
  • This should always be a topic during release sig meetings as the roadmap will continually change.
  • Need to edit this doc https://docs.google.com/spreadsheets/d/1U_XAw9YJoPE3FlYeBKUz4kYjFRDS09NS3_YuZSZJ2qA/edit#gid=1112481565
• Election of chair and co-chair - issue opened at #66
  • Need a time frame that is soon as @Ulrick28 will need to step down as chair and cannot be co-chair
• Discuss adding Alpha and Beta phases to our release process, starting in 2023, Proposed by @jeremyong-az
  • Goal is to provide known quality points to users. Many users will not use nightly builds, but would test a project integration/upgrade with a beta build. This provides additional avenues of user testing.
  • Need to determine if the impact (gain) of the alpha/beta releases worth the added complexity.
  • Need to define what determines Alpha, what determines Beta.
  • Need to determine if this is branches or just tags in stabilization (tags will be easier to manage and less complexity, a branch is more obvious to users)
  • We would need to expose alpha and beta builds on the download page during a release phase. This will require coordination with sig-build.
  • We would need more documentation around the alpha, beta, and final, primarily to cover feature and/or bug fix deltas.
  • We would need to develop a mechanism for users to report issues against the builds
  • Soonest we should start Alpha and Beta is 2023. This allows us time to develop a plan, get feedback, document the process, and communicate the final process. We do not want developers having to adapt 'on the fly' during the October 2022 release.

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

Proposed SIG-Release meeting agenda for December-07-21

Meeting Details

• Date/Time: December 07, 2021 @ 06:00pm UTC / 10:00am PT
• Location: Discord SIG-Release Voice Room
• Moderator: Terry Michaels
• Note Taker Tony Balandiuk

The SIG-Release Meetings repo contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting?

Meeting Agenda

• 12/2 release status restrospective
  • Acknowledgement of release
  • When should a discussion be held for how to improve the release mechanism for future releases?
• O3DE January Point Release #27
  • Technical Steering Committee is onboard with a point release.
  • Tentative date? Sometime between January 11th - 13th to start the discussion.
    • Avoids bleeding into weekend
    • Allows everyone a week to recover from the holiday breaks
    • Gives time for QA and address any issues after the break (Note that December 20th - January 2nd are very slow for contributors as most people are out during this time)
• For a variety of reasons (technical and marketing) should we consider utilizing YY.MM.Version instead of YYMM.Version?
  • Wix (windows installer framework) and windows has issues with each position being over 255, except the last position which can be 65k in value.
  • Marketing Committee considers yy.mm.version friendlier than yymm.version
  • If we are going to change our versioning, it is better to do it early in O3DE's life cycle.
• Need to coordinate with marketing committee on friendly names
  • Using YY.MM.version as a part of the friendly name led to confusion in documentation, the installer, the editor splash screen, and how to communicate the release. This confusion was due to how close 21.11 is to our actual version of 2111.1.
• Discuss any updates for Definition of Long Term Support (LTS) of Releases (ongoing discussion)
• Future release cadence (ongoing discussion)?
  • Currently scheduled for ~6 months
• Elections are currently being held

Outcomes from Discussion topics

Discuss outcomes from agenda

Action Items

Create actionable items from proposed topics

Open Discussion Items

List any additional items below!

SIG-Release 11/30 release notes

Please fill any info related to the below for the 11/30 release notes: Note this has a due date of Friday Nov 12th, 2021

• Features
• Bug fixes (GHI list if possible)
• Deprecations
• Known issues

Proposed release naming guidance from Marketing Committee

The Marketing Committee submits the following message for Sig-Release's review:

Release Naming Guidance

The use of 'major' and 'point' to describe the type of release is optional, but approved, for shorthand/non-technical descriptions.

Example: ...the last major release...
Example: ...an upcoming point release...

A major release follows the format:
<Last two digits of year>.<Last two digits of month>.<Versioning digit = 0>
A point release re-uses the year and month of the previous major release and increments the versioning digit by one.

Example: A major release in June 2025 would be named 25.06.0
Example: A point release in July 2025 would be named 25.06.1
Example: A second point release in January 2026 would be named 25.06.2
Example: A major release in January 2026 would be named 26.01.0

A major release can be referred to in non-technical descriptions without the versioning digit.

Example: 25.06, in general, would refer to a major release from June 2025.

The marketing committee recommends that friendly names are not used for releases.

Sig-Release 2022 Roadmap

This issue will track any Roadmap items that SIG-Release will contribute to the O3DE Roadmap for 2022.

• Date TBD Formalize the release process. This will be done in advance of the 22.10.0 release.
• Oct 13, 2022 O3DE 22.10.0 Release #64

Please comment under this issue with any other roadmap items for sig-release