| categories | stability-level | issue | feature-team | promotes | promoted-by | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
<The entire document should be one to two pages long. We will write each analysis document as if it is a conversation with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments.>
<Define the requirement here. Be clear and succinct, you should be able to clearly define the context or problem in two or three paragraphs (if not sentences). Try to define the problem in the overall context and not to get into too much technical detail at this point.>
<List the projects or components that are affected by the feature. List them using their Git repositories.>
<Describe the requirements that must be fulfilled by this feature.>
<For analyses of a promotion of an existing feature to 'preview' or 'community' stability, only list new requirements; existing requirements from the feature being promoted are assumed to continue unless otherwise noted in the 'Changed requirements' section. Other analyses, including those for promotion to the 'default' stability level, must list all requirements.>
<Only relevant for analyses of a promotion of an existing feature to 'preview' or 'community stability. Other analyses should remove this section.>
<For any existing requirements from the feature being promoted that are being changed or removed, describe the change.>
<Use this section to explicitly discuss things that readers might think are required but which are not required.>
<Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified incompatibility be avoided?>
<Does the proposed work change the default value of any current configuration attributes? Does it change the configuration generated by any current Galleon layers?>
<Does the proposed work affect the ability to run WildFly running an existing configuration? Is there anything else about the proposed work that may require changes to the WildFly server migration tool?>
<Does this feature change the behavior of deployments in incompatible ways? If yes please detail what is the deployment issue observed when no change is done, and what is the change needed to solve the deployment issue>
<This section is optional. If you have a complex feature which can not be delivered all in one go, suggest the strategy.>
<Identify the level of compatibility this feature will have with the existing admin clients (JBoss CLI and the Admin Console / HAL). Identify any follow up work that will be required in the clients and link issues created to track this work.>
<Depending on the selected stability level, the appropriate section below should be completed, including a brief description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections may be removed as needed.>
-
Experimental - No test plan is required. Basic unit / integration tests should be added during development.
-
Preview - a brief high-level description of the testing approach should be added here, including types of tests added (unit, integration, smoke, component, subsystem, etc.) Note that not all test types are required for a particular feature, so include a description of what is being tested and the approach chosen to perform the testing.
-
Community - this level should include everything in the 'Preview' stability level, plus the following additional testing as relevant:
-
Manual tests: briefly describe checks to be performed during one-time exploratory testing. The purpose of this testing is to check corner cases and other cases that are not worth implementing as automated tests. Typical checks are: bad configurations are easy to reveal, attribute descriptions and error messages are clear, names are descriptive and consistent with similar resources, default values are reasonable. If there is an existing quickstart affected by the feature, manual checks include following the quickstart’s guide and verifying functionality.
-
Miscellaneous checks: Manual checks for significant changes in server performance, memory and disk footprint should be described here. These checks are not always relevant, but consideration of these impacts, and others, are strongly encouraged and should be described here. Fully qualified test case names should be provided along with a brief description of what the test is doing.
-
Integration tests - at the 'Community' stability level, complete integration tests should be provided.
-
Compatibility tests - if backwards compatibility is relevant to the feature, then describe how the testing is performed.
-
-
Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise.
<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of the PR to wildfly main, or as a follow up PR if the feature is in wildfly-core. In some cases though the feature will bring additional content (such as quickstarts, guides, etc.). Indicate which of these will happen>
<Draft verbiage for up to a few sentences on the feature for inclusion in the Release Note blog article for the release that first includes this feature. Example article: https://www.wildfly.org/news/2024/01/25/WildFly31-Released/. This content will be edited, so there is no need to make it perfect or discuss what release it appears in.>