In an earlier article on CentOS Linux 7 (1708), I explained the the basic release process and about things like the Continuous Release (CR) repository. I am not going to go into detail about those two topics here, just update you on the process.
The packages that make up what will be our CentOS Linux 7 (1708), minus the distribution installer and the new release files, are now in our CR repository. Package release announcements. The release notes are here for the release.
The CentOS team rolled in a bugfix to iptables to prevent the service from not restarting on any systems that do not use firewalld but have ip6tables and iptables on. We used this patch in the fix. We do not normally do that (normally only fix bugs when the source RPM is released upstream), but in this case we decided to because of the impact of no firewall on a huge number of internet facing machines that use CentOS. The new package versioning (iptables-*1.4.21-18.0.el7*) is such that when a replacement is released by Red Hat for RHEL and after we build it, it will replace our version in this release.
We had a record number of missing build requirements (that is, things required to build the release that are not actually in the distribution to run the released packages). These packages are not part of RHEL proper and each one has to be researched and an appropriate package found (usually from EPEL or the Fedora Archives) to build the packages. In the 1708 release, we had 11 of those source packages to find. In the previous four CentOS release cycles there were a total of 5.
There are a larger number of services that have been rebased to newer versions in this release than in the past. This seems to be a trend by the RHEL engineers to give the releases newer software, especially in the desktop/GUI areas, while still backporting most of the server related packages to maintain ABI/API compatibility. The release notes talk about specific libraries that were rebased. I like rebases, they give us newer stuff and who doesn't like that 🙂 .. but, they also mean newer shared libraries and that makes finding the correct build order for packages even more important. This lead to a larger number of packages requiring rebuilding more than one time during the process because they had older shared library links initially.
The CR repository is not on by default and it is an opt-in process. It usually takes 2-3 weeks after the CR release for the final release (to get the installer working, compile the full tree from older releases and the newer updates, generate install media, cloud images, vagrant boxes, container images, etc.).
Everyone wants to upgrade immediately (me too 🙂 ), but you may need to hold off for some of the following reasons.
Each install is unique and should be tested before upgrading. Many of the libraries have compatibility versions in the release an some things will work from the above, others will not. yum should tell you any errors if it can not upgrade.
You can enable CR with the command: yum-config-manager --enable cr
After that you can upgrade with the command: yum update