Forgot the link reference to semantic versioning
  https://semver.org/


Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

(In reply to Direct Docs Feedback from comment #0)
> I always recommend my customers to follow this section, when they ask about
> how to proceed when updating Operating System is required.
> As not always a new bugfix-version is available (I guess even the wording
> minor-version is wrong. Following the guideline from semantic versioning
> [1], we're talking about bugfix version), a os-update might be necessary.
> 
> So I would like to have this section re-phrased to also catch the
> requirement of updating Satellite from OS-level point of view. 
> Instead of doing a `yum update` the customer always should perform the
> foreman-maintain procedure, which includes the os-upgrade as well.
> 
> Thanks
> 
> Reported by: rhn-support-sfroemer
> 
> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/
> upgrading_and_updating_red_hat_satellite/
> updating_satellite_server_capsule_server_and_content_hosts#annotations:
> 595b7f76-7d51-4bed-9a44-feebda7368c4

Hi Steffen, 

Thank you for raising this bug. I would like to ask you for further clarification. We are trying to figure out exactly what needs to be changed here. 

With regards to `yum update`, in the docs, we say to use `yum update` only for Capsule, based on the information about Capsule support for foreman-maintain, which still remains limited. Please see, BZ#1535466 - [RFE] Foreman maintain support for Capsules.


For Satellite, we have used foreman-maintain https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/upgrading_and_updating_red_hat_satellite/updating_satellite_server_capsule_server_and_content_hosts#updating_satellite_server_to_next_minor_version

There is potential here to introduce confusion with changing the language about how we refer to versions. Satellite 6 has been the distinct product name rather than the version. I think that any changes of major, minor, patch, would probably have to come from product management. 

I would appreciate any clarification you can provide. 

Thank you, 

Melanie

1Hi Steffen, 

different upgrade scenarios and the way how we refer to them are described in Chapter 1. Upgrade Overview [2]. There are three scenarios and the following wording:
1) Update your Satellite (to the lastest z-version and after. For example, Satellite 6.5.1 to Satellite 6.5.3 or 6.5.3.0 to Satellite 6.5.3.1.
2) Upgrade Satellite to the next y-version. For example Satellite 6.4 to Satellite 6.5.
3) Migrate Satellite to the next x-version. For example 5 to Satellite 6. 

Each of this upgrade/update includes updating the OS too.

[2] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/upgrading_and_updating_red_hat_satellite/upgrading_process_overview#upgrading_prerequisites

Thank you

Hi,

what I would like to have covered in the update-documentation, is a scenario, where RHEL-updates are available, but no newer z-stream packages for satellite itself.
It's a scenario, where you might install a security patch or something like that. In general a customer might to use `yum update` in this case.

But as already written, I would like to avoid that and would like to push customers to use `foreman-maintain` command even when there is _no_ satellite update available.
But exactly this scenario is not covered in documentation. 

Something like "In any case of update, a customer would like to install on satellite, he has to use foreman-maintain command, which will cover the os-updates as well"

Does it make more sense now?

The scenario to update the Satellite base operating system is now considered in BZ#1759588. It should be performed by either running `foreman-maintain packages update \\*` or `foreman-maintain upgrade`.Any decision made will be revealed in future comments on BZ#1759588. We can update our documentation accordingly when the decision is made.

Hi Martin,

there is a request from customers to have a procedure that describes how to update the os where Satellite is installed without updating the Satellite itself. Do we support such a configuration?

BZ#1759588 mentions entering the `satellite-maintain packages update \\*` command to update all packages, this is something that can cause errors in Satellite itself.
Should this be done via `satellite-maintain upgrade run --target-version 6.6.z` instead?

Thank you

In 6.6, updating all packages via satellite-maintain packages is not supported.

In 6.7, as per BZ#1759588, the output of the satellite-maintain packages update has the following warning:
~~~~
WARNING: No specific packages to update were provided
so we are going to update all available packages.
It is recommended to update everything only as part of upgrade
of the Satellite to the next version. 
To Upgrade to next version use 'foreman-maintain upgrade'
~~~~

We recommend updating all packages on the base OS of Satellite only as part of the Satellite update. Hence, if required to update packages, update Satellite Server via `satellite-maintain upgrade`.

Feel free to re-open this bug if you have any further concerns.

Thank you