📚 [Documentation]: improve tagging criteria

[mishaschwartz]

Description

The tagging criteria when creating a new release mostly refers to how components interact, not how they impact the end-user:

birdhouse-deploy/birdhouse/README.rst

Lines 324 to 336 in 1528ba1

	#. MAJOR version when the API or user facing UI changes that requires
	significant documentation update and/or re-training of the users. Also
	valid when a big milestone has been reached (ex: DACCS is released).
	#. MINOR version when we add new components or update existing components
	that also require change to other existing components (ex: new Magpie that
	also force Twitcher and/or Frontend update) or the change to the existing
	component is a major one (ex: major refactoring of Twitcher, big merge
	with corresponding upstream component from birdhouse project).
	#. PATCH version when we update existing components without impact on other
	existing components and the change is a minor change for the existing
	component.

This is fine but a bit ambiguous we need to also consider how these changes affect users. I suggest changing the language to:

• MAJOR: (no change needed)
• MINOR: requires changes to configuration settings or when a user's workflow would be affected as a result of the change. Some examples:
  • an update to a component that requires changes to be made to the configuration settings for that same component or others
  • an update to any default setting for an existing component
  • an update to a Jupyterlab image, weaver deployment, etc. that requires changes to users' workflow files in order for them to run properly
• PATCH: requires no changes to configuration settings or introduces optional additional configurations. Some examples:
  • a new optional component is added
  • a fully backwards compatible change is made to an existing component

I think we should also add in some language about requiring an addition to the migration guide for all major and minor updates.

References

Information	Value
Server/Platform URL	all
Related issues/PR	#475
Related documentation	- https://github.com/bird-house/birdhouse-deploy/blob/master/birdhouse/README.rst#tagging-policy - https://github.com/bird-house/birdhouse-deploy/blob/master/docs/source/migration_guide.rst

[tlvu]

I agree with the suggestion. Also we should review any configs that is not generic (like Ouranos Jupyter specific image in #475 (comment)) and if we can not make them optional, not enabled by default, we document them clearly they are not generic.

The components to review are those that were previously enable by default and now they are not. The default values of their configs might be able to change to something more generic.