From b5e3fa0895723eebe3a3987ecbe62dc3ab5701cb Mon Sep 17 00:00:00 2001 From: camikazegreen Date: Fri, 7 Jun 2024 11:03:52 -0700 Subject: [PATCH 1/5] adding policy recommendations for Experimental Modules --- RELEASES.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/RELEASES.md b/RELEASES.md index f2683fa837..47fde7ef26 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -81,6 +81,41 @@ Beta releases serve as a preview of the upcoming stable release and are meant fo ### Release Candidates (rc) Release candidates are the final step before the stable release. These versions are considered feature complete, with all proposed features implemented and bugs addressed. The primary purpose of an RC is to ensure that there are no critical issues that were missed during beta testing. If no significant problems are identified in an RC, it can be promoted to a stable release. However, if issues are found, they are addressed, and a new RC is issued for testing. +## Experimental Modules +When adding new features to Quickstart, particularly large or complicated features, we usually add these modules as "experimental" to indicate to site owners that these modules are not fully tested or feature complete and will likely experience significant or breaking changes. These modules should only be used by site owners that are actively tracking Quickstart development and are prepared to resolve the consequences of breaking changes. + +Any modules with the experimental status bypass all of the minor release controls so that ongoing development can be released quickly through patch releases. This allows for fast development of new sites that are motivating the creation of the feature. + +### Best Practices for Using Experimental Modules +- **Ideal for**: Testing new features on staging or development sites before production deployment. +- **Risks**: May introduce breaking changes; not recommended for critical production sites without thorough testing. + +### Identifying Experimental Modules +To add a module as experimental, define the package as 'The University of Arizona - Experimental' in the module's info.yml file. + +### Graduating an Experimental Module to Stable +For the overall stability of the Quickstart project, the number of Experimental modules at any time should be kept to a minimum, and effort should be made to convert Experimental Modules to Stable with each minor release. + +## Experimental Modules + +### Identifying Experimental Modules +To add a module as experimental, define the package as 'The University of Arizona - Experimental' in the module's info.yml file. + +### Transition Plan for Experimental Modules + +To ensure the stability and reliability of Quickstart, the number of Experimental modules should be minimized, and efforts should be made to convert Experimental modules to Stable with each minor release. + +#### Qualifications for Updating from Experimental to Stable +- **Feature Complete**: The module should have all planned features fully implemented. +- **Testing on Live Websites**: Ideally, the module should be installed on live websites for at least one complete minor release cycle with all known issues resolved. +- **Stable Parent Modules**: All parent modules of the experimental module should be in a stable state. + +#### Transition Plan +- **Testing Phases**: The module should be fully tested in Probo.ci before being moved to Stable. The pre-release testing phase should incorporate complete testing on sample sites during the minor release cycle. +- **Documentation**: Update and finalize comprehensive documentation covering the module’s features, configurations, and any known issues. +- **Review and Approval**: Conduct a thorough review and seek approval from the development team and key stakeholders before transitioning the module to a stable release. + + ## Update hook numbering convention In order to allow update hooks to be added to different minor release branches From 832acd240bf9113d3b9304856fcc6cf0f684f5ad Mon Sep 17 00:00:00 2001 From: Chris Green Date: Fri, 7 Jun 2024 11:42:43 -0700 Subject: [PATCH 2/5] Update RELEASES.md --- RELEASES.md | 57 +++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 40 insertions(+), 17 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 47fde7ef26..772c46fdd5 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -82,40 +82,63 @@ Beta releases serve as a preview of the upcoming stable release and are meant fo Release candidates are the final step before the stable release. These versions are considered feature complete, with all proposed features implemented and bugs addressed. The primary purpose of an RC is to ensure that there are no critical issues that were missed during beta testing. If no significant problems are identified in an RC, it can be promoted to a stable release. However, if issues are found, they are addressed, and a new RC is issued for testing. ## Experimental Modules -When adding new features to Quickstart, particularly large or complicated features, we usually add these modules as "experimental" to indicate to site owners that these modules are not fully tested or feature complete and will likely experience significant or breaking changes. These modules should only be used by site owners that are actively tracking Quickstart development and are prepared to resolve the consequences of breaking changes. - -Any modules with the experimental status bypass all of the minor release controls so that ongoing development can be released quickly through patch releases. This allows for fast development of new sites that are motivating the creation of the feature. +When adding new features to Quickstart, particularly large or complicated +features, we usually add these modules as "experimental" to indicate to site +owners that these modules are not fully tested or feature complete and will +likely experience significant or breaking changes. These modules should only be +used by site owners that are actively tracking Quickstart development and are +prepared to resolve the consequences of breaking changes. + +Any modules with the experimental status bypass all of the minor release +controls so that ongoing development can be released quickly through patch +releases. This allows for fast development of new sites that are motivating the +creation of the feature. ### Best Practices for Using Experimental Modules -- **Ideal for**: Testing new features on staging or development sites before production deployment. -- **Risks**: May introduce breaking changes; not recommended for critical production sites without thorough testing. +- **Ideal for**: Testing new features on staging or development sites before + production deployment. +- **Risks**: May introduce breaking changes; not recommended for critical + production sites without thorough testing. ### Identifying Experimental Modules -To add a module as experimental, define the package as 'The University of Arizona - Experimental' in the module's info.yml file. +To add a module as experimental, define the package as 'The University of +Arizona - Experimental' in the module's info.yml file. ### Graduating an Experimental Module to Stable -For the overall stability of the Quickstart project, the number of Experimental modules at any time should be kept to a minimum, and effort should be made to convert Experimental Modules to Stable with each minor release. +For the overall stability of the Quickstart project, the number of Experimental +modules at any time should be kept to a minimum, and effort should be made to +convert Experimental Modules to Stable with each minor release. ## Experimental Modules ### Identifying Experimental Modules -To add a module as experimental, define the package as 'The University of Arizona - Experimental' in the module's info.yml file. +To add a module as experimental, define the package as 'The University of +Arizona - Experimental' in the module's info.yml file. ### Transition Plan for Experimental Modules -To ensure the stability and reliability of Quickstart, the number of Experimental modules should be minimized, and efforts should be made to convert Experimental modules to Stable with each minor release. +To ensure the stability and reliability of Quickstart, the number of +Experimental modules should be minimized, and efforts should be made to convert +Experimental modules to Stable with each minor release. #### Qualifications for Updating from Experimental to Stable -- **Feature Complete**: The module should have all planned features fully implemented. -- **Testing on Live Websites**: Ideally, the module should be installed on live websites for at least one complete minor release cycle with all known issues resolved. -- **Stable Parent Modules**: All parent modules of the experimental module should be in a stable state. +- **Feature Complete**: The module should have all planned features fully + implemented. +- **Testing on Live Websites**: Ideally, the module should be installed on live + websites for at least one complete minor release cycle with all known issues + resolved. +- **Stable Parent Modules**: All parent modules of the experimental module + should be in a stable state. #### Transition Plan -- **Testing Phases**: The module should be fully tested in Probo.ci before being moved to Stable. The pre-release testing phase should incorporate complete testing on sample sites during the minor release cycle. -- **Documentation**: Update and finalize comprehensive documentation covering the module’s features, configurations, and any known issues. -- **Review and Approval**: Conduct a thorough review and seek approval from the development team and key stakeholders before transitioning the module to a stable release. - - +- **Testing Phases**: The module should be fully tested in Probo.ci before being + moved to Stable. The pre-release testing phase should incorporate complete + testing on sample sites during the minor release cycle. +- **Documentation**: Update and finalize comprehensive documentation covering + the module’s features, configurations, and any known issues. +- **Review and Approval**: Conduct a thorough review and seek approval from the + development team and key stakeholders before transitioning the module to a + stable release. ## Update hook numbering convention In order to allow update hooks to be added to different minor release branches From 3975899fbf95422b182e6bf739f4008b42d04ba2 Mon Sep 17 00:00:00 2001 From: Chris Green Date: Fri, 7 Jun 2024 11:43:03 -0700 Subject: [PATCH 3/5] Update RELEASES.md --- RELEASES.md | 1 + 1 file changed, 1 insertion(+) diff --git a/RELEASES.md b/RELEASES.md index 772c46fdd5..153b55f529 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -139,6 +139,7 @@ Experimental modules to Stable with each minor release. - **Review and Approval**: Conduct a thorough review and seek approval from the development team and key stakeholders before transitioning the module to a stable release. + ## Update hook numbering convention In order to allow update hooks to be added to different minor release branches From b136d558eb9685a7220138db77dd4b8b88a22ec8 Mon Sep 17 00:00:00 2001 From: camikazegreen Date: Fri, 7 Jun 2024 12:15:43 -0700 Subject: [PATCH 4/5] removing duplicate section --- RELEASES.md | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 153b55f529..50c382d909 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -100,20 +100,9 @@ creation of the feature. - **Risks**: May introduce breaking changes; not recommended for critical production sites without thorough testing. -### Identifying Experimental Modules -To add a module as experimental, define the package as 'The University of -Arizona - Experimental' in the module's info.yml file. - -### Graduating an Experimental Module to Stable -For the overall stability of the Quickstart project, the number of Experimental -modules at any time should be kept to a minimum, and effort should be made to -convert Experimental Modules to Stable with each minor release. - -## Experimental Modules - -### Identifying Experimental Modules -To add a module as experimental, define the package as 'The University of -Arizona - Experimental' in the module's info.yml file. +### Classifying Modules as Experimental +To add a module as experimental, define the `package` as +`'The University of Arizona - Experimental'` in the module's `info.yml` file. ### Transition Plan for Experimental Modules From ab0709240925d1002274940a2cc33eaf4abecd4f Mon Sep 17 00:00:00 2001 From: camikazegreen Date: Fri, 2 Aug 2024 10:18:53 -0700 Subject: [PATCH 5/5] incorporating Joes suggestions. --- RELEASES.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 50c382d909..99dc7a1003 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -81,11 +81,11 @@ Beta releases serve as a preview of the upcoming stable release and are meant fo ### Release Candidates (rc) Release candidates are the final step before the stable release. These versions are considered feature complete, with all proposed features implemented and bugs addressed. The primary purpose of an RC is to ensure that there are no critical issues that were missed during beta testing. If no significant problems are identified in an RC, it can be promoted to a stable release. However, if issues are found, they are addressed, and a new RC is issued for testing. -## Experimental Modules +## Experimental Features When adding new features to Quickstart, particularly large or complicated -features, we usually add these modules as "experimental" to indicate to site -owners that these modules are not fully tested or feature complete and will -likely experience significant or breaking changes. These modules should only be +features, we usually encapsulate these in modules labeled as "experimental" to indicate to site +owners that these features are not fully tested or feature-complete and will +likely undergo significant or breaking changes. These features should only be used by site owners that are actively tracking Quickstart development and are prepared to resolve the consequences of breaking changes.