CentOS announce - Mar 2015 - Release for CentOS Linux 7 (1503 ) on x86_64

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


We would like to announce the general availability of CentOS Linux 7
(1503) for 64 bit x86 compatible machines.

This is the second major release for CentOS-7 and is tagged as 1503.
This build is derived from Red Hat Enterprise Linux 7.1

As always, read through the Release Notes at :
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7 - these notes
contain important information about the release and details about some
of the content inside the release from the CentOS QA team. These notes
are updated constantly to include issues and incorporate feedback from
the users.

- ----------
Updates, Sources, and DebugInfos

This merges in all base, updates, and CR (continuous release)
components released in the month of March 2015. If you have been using
the CR repos on your previous CentOS Linux 7 install, you already have
all the components used to compose this new release.

As with all CentOS Linux 7 components, this release was built from
sources hosted at git.centos.org. In addition, SRPMs that are a
byproduct of the build (and also considered critical in the code and
buildsys process) are being published to match every binary RPM we
release. Sources will be available from vault.centos.org in their own
dedicated directories to match the corresponding binary RPMs. Since
there is far less traffic to the CentOS source RPMs compared with the
binary RPMs, we are not putting this content on the main mirror
network. If users wish to mirror this content they can do so using the
reposync command available in the yum-utils package. All CentOS source
RPMs are signed with the same key used to sign their binary
counterparts. Developers and end users looking at inspecting and
contributing patches to the CentOS Linux distro will find the code
hosted at git.centos.org far simpler to work against. Details on how
to best consume those are documented along with a quick start at :
http://wiki.centos.org/Sources

Debuginfo packages are also being signed and pushed. Yum configs
shipped in the new release file will have all the context required for
debuginfo to be available on every CentOS Linux install.

This release supersedes all previously released content for CentOS
Linux 7, and therefore we highly encourage all users to upgrade their
machines. Information on different upgrade strategies and how to
handle stale content is included in the Release Notes.

For the CentOS-7 build and release process we adopted a very open
process. The output of the entire buildsystem is made available, as it
is built, at http://buildlogs.centos.org/ - we hope to continue with
that process for the life of CentOS Linux 7, and hope to attempt
bringing CentOS-5 and CentOS-6 builds into the same system.

- ----------
Release file handling

This release splits the /etc/centos-release from /etc/redhat-release
to better indicate the relationship between the two distributions.
There are also changes to the /etc/os-release file to incorporate
changes needed by the new abrt stack.

- ----------
Download

In order to conserve donor bandwidth, and to make it possible to get
the mirror content sync'd out as soon as possible, we recommend using
torrents to get your initial installer images:

Details on the images are available on the mirrors at
http://mirror.centos.org/centos/7/isos/x86_64/0_README.txt - that file
clearly highlights the difference in the images, and when one might be
more suitable than the others.

The sizes, sha256 sums and torrents for the ISO files:

* CentOS-7-x86_64-Minimal-1503.iso
  Size: 591396864
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-15
03.torrent
  sha256sum:
0b8482dc7e3076749f7fd914487ec6280539d3ba1f10c5b73c94b632f987f011

* CentOS-7-x86_64-DVD-1503.iso
  Size: 4236247040
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1503.t
orrent
  sha256sum:
1817a1689b3c646a6473c93012e06307c6b659000ccffd188a3f4d0a0b531ba9

* CentOS-7-x86_64-Everything-1503.iso
  Size: 7517241344
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Everything
- -1503.torrent
  sha256sum:
3cef58a3a03aff3ea194e63fdc95f03548b292e6f57e4a931a8d5453a6697661

* CentOS-7-x86_64-LiveGNOME-1503.iso
  Size: 1124073472
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveGNOME-
1503.torrent
  sha256sum:
2cfc9fab2edb0be51b75ee63528b61cad79489129d2aad1713eeed1b4117ab47

* CentOS-7-x86_64-LiveKDE-1503.iso
  Size: 1310720000
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveKDE-15
03.torrent
  sha256sum:
6b2cd1c30092e9a141a458d40d0fcba74207b6c80e4f68dc7f800fbe1d7bae1b

* CentOS-7-x86_64-LiveCD-1503.iso
  Size: 729808896
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveCD-150
3.torrent
  sha256sum:
96ee805573d0617ee11704e7973b55387adef13c6efdc82d50d287dba00dfaf1

* CentOS-7-x86_64-NetInstall-1503.iso
  Size: 377487360
  Torrent:
http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-NetInstall
- -1503.torrent
  sha256sum:
498bb78789ddc7973fe14358822eb1b48521bbaca91c17bd132c7f8c903d79b3

The iso files are also available for direct download from
http://mirror.centos.org/centos/7/isos/x86_64

* CentOS 7 1503 Docker Container:  ' docker pull centos' will now give
you the 1503 container image. You can see the official CentOS Linux
container tags at : https://registry.hub.docker.com/_/centos/

- ----------
Special Interest Groups

The CentOS Linux distribution is built, managed, and released by the
CentOS Core SIG. In addition, we also have the following SIGs that are
doing an amazing job expanding and building on the base Linux platform:

* Cloud SIG @ http://wiki.centos.org/SpecialInterestGroup/Cloud is
working to deliver various cloud controller infrastructure including
OpenStack. They have a fully functional, feature complete RDO stack
now available for testing with CentOS Linux 7 at
http://buildlogs.centos.org/centos/7/cloud/openstack-rdo/

* Cloud Instance SIG @
http://wiki.centos.org/SpecialInterestGroup/CloudInstance aims to
deliver VM images for use in various cloud and virtualised ecosystems
including AWS (
https://aws.amazon.com/marketplace/seller-profile?id=16cb8b03-256e-4dde-
8f34-1b0f377efe89
) and Docker ( https://registry.hub.docker.com/_/centos/ )

 * Virtualization SIG @
http://wiki.centos.org/SpecialInterestGroup/Virtualization includes
upstream virtualization and hypervisor related projects including Xen
( http://www.xenproject.org ), oVirt ( http://www.ovirt.org/ ), and
Docker ( http://docker.io ). They also work to build and release
support tools around these virtualization technologies.

* Storage SIG @ http://wiki.centos.org/SpecialInterestGroup/Storage
includes the Gluster Project ( http://www.gluster.org/ ), Ceph (
http://ceph.com ), OpenAFS ( http://www.openafs.org ) and the SCST
project ( http://scst.sourceforge.net/ ). Gluster builds for CentOS,
that track upstream community code are available for testing now at
http://buildlogs.centos.org/centos/7/storage/gluster/

* Software Collections SIG @
http://wiki.centos.org/SpecialInterestGroup/SCLo is working on
documenting and then delivering software collections built for newer
versions of in-distro content. Their aim is to deliver a community and
contributor friendly mechanism for SCL's in an easy to consume format.

* Atomic SIG @ http://wiki.centos.org/SpecialInterestGroup/Atomic is
working on building, maintaining, and delivering a CentOS Atomic host
( http://projectatomic.io ). Testing and development builds including
AWS EC2 instances and Vagrant boxes are now available at
http://wiki.centos.org/SpecialInterestGroup/Atomic/Download

In addition to these, the CentOS Artwork and CentOS Promo SIGs help
with promo content and helping organise Dojos around the world.

SIGs are a great way for people to come together and deliver content
around a specific area into the wider CentOS ecosystem and we welcome
groups to come together with low barriers to entry and plenty of
resources to offer the groups. Details on the process can be found at
http://wiki.centos.org/SpecialInterestGroup

- ----------
Dojo

We try and organise Dojos in various parts of the world as a one day
event, to bring together people who use CentOS and others who are keen
to learn about CentOS. The day's focus is on sharing technical
knowledge and success stories. It's also a great place to meet and
talk about upcoming technologies and learn how others are using them
on CentOS Linux.

In the coming months we hope to host events in London, Bangalore,
Sweden, Germany, Spain, and in many parts of the USA. If you would
like to help organise a Dojo, do drop by the centos-promo list at
http://lists.centos.org/mailman/listinfo/centos-promo

- ----------
Getting Help

The CentOS ecosystem is sustained by community driven help and
guidance. The best place to start for new users is at
http://wiki.centos.org/GettingHelp

- ----------
Contributors

This release was made possible due to the hard work of many people,
foremost on that list are the Red Hat Engineers for producing a great
distribution, without them CentOS Linux would look very different.

We are also looking for people to get involved with the QA process in
CentOS, if you would like to join this please introduce yourself on
the centos-devel list (
http://lists.centos.org/mailman/listinfo/centos-devel ).


- ----------
Thanks

I would also like to thank our donors and sponsors for their continued
support for the project. And to everyone who contributed with ideas,
code, test feedback, and promoting CentOS Linux into the ecosystem.

Enjoy!

- -- 
Karanbir Singh, Project Lead, The CentOS Project
+44-207-0094455 | http://www.centos.org/ | twitter.com/CentOS

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJVGsvBAAoJEI3Oi2Mx7xbt1xAH/0ZoWz65f/O8URzsleO4DaiD
Wy8YMWaPVTlLDnik7EukYSueT1bE9ziB3DxycQJVXz8HTABdjNugN6Ouy83bCY2a
17t6F0VGY0ZRZe6Uqv8rb2xiFnFR/ssy9s921vJVcpzaSLgKl2/D5ed1aSsLaxLw
CdpYcC7t/8xbkpnCtoyQ2nko0Jzj8fYPr8wCUKTgnf0BXyXYYcuNsi+J6HKzlExc
KXHuvLDjXCjOVi4X7BLbn2F5N7bwBcmjYWC/hX1oAlD2uvbbNg/+mDbAu9QtWmeC
RthUq5uwpA05i9MvyMU5/ODS1NpIg3f+JybPLTp9zaFU6hXmJSvOR679wZbFdUc=Z60w
-----END PGP SIGNATURE-----

As a CentOs newbie,  I'm not sure, will we still have CentOS 7.1 which
derive from RHEL 7.1?
or this is the new naming conversion for CentOS 7.

Thanks!
-Ryan
> On Apr 1, 2015, at 12:30 AM, Karanbir Singh <kbsingh at centos.org>
wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> We would like to announce the general availability of CentOS Linux 7
> (1503) for 64 bit x86 compatible machines.
> 
> This is the second major release for CentOS-7 and is tagged as 1503.
> This build is derived from Red Hat Enterprise Linux 7.1
> 
> As always, read through the Release Notes at :
> http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7 - these notes
> contain important information about the release and details about some
> of the content inside the release from the CentOS QA team. These notes
> are updated constantly to include issues and incorporate feedback from
> the users.
> 
> - ----------
> Updates, Sources, and DebugInfos
> 
> This merges in all base, updates, and CR (continuous release)
> components released in the month of March 2015. If you have been using
> the CR repos on your previous CentOS Linux 7 install, you already have
> all the components used to compose this new release.
> 
> As with all CentOS Linux 7 components, this release was built from
> sources hosted at git.centos.org. In addition, SRPMs that are a
> byproduct of the build (and also considered critical in the code and
> buildsys process) are being published to match every binary RPM we
> release. Sources will be available from vault.centos.org in their own
> dedicated directories to match the corresponding binary RPMs. Since
> there is far less traffic to the CentOS source RPMs compared with the
> binary RPMs, we are not putting this content on the main mirror
> network. If users wish to mirror this content they can do so using the
> reposync command available in the yum-utils package. All CentOS source
> RPMs are signed with the same key used to sign their binary
> counterparts. Developers and end users looking at inspecting and
> contributing patches to the CentOS Linux distro will find the code
> hosted at git.centos.org far simpler to work against. Details on how
> to best consume those are documented along with a quick start at :
> http://wiki.centos.org/Sources
> 
> Debuginfo packages are also being signed and pushed. Yum configs
> shipped in the new release file will have all the context required for
> debuginfo to be available on every CentOS Linux install.
> 
> This release supersedes all previously released content for CentOS
> Linux 7, and therefore we highly encourage all users to upgrade their
> machines. Information on different upgrade strategies and how to
> handle stale content is included in the Release Notes.
> 
> For the CentOS-7 build and release process we adopted a very open
> process. The output of the entire buildsystem is made available, as it
> is built, at http://buildlogs.centos.org/ - we hope to continue with
> that process for the life of CentOS Linux 7, and hope to attempt
> bringing CentOS-5 and CentOS-6 builds into the same system.
> 
> - ----------
> Release file handling
> 
> This release splits the /etc/centos-release from /etc/redhat-release
> to better indicate the relationship between the two distributions.
> There are also changes to the /etc/os-release file to incorporate
> changes needed by the new abrt stack.
> 
> - ----------
> Download
> 
> In order to conserve donor bandwidth, and to make it possible to get
> the mirror content sync'd out as soon as possible, we recommend using
> torrents to get your initial installer images:
> 
> Details on the images are available on the mirrors at
> http://mirror.centos.org/centos/7/isos/x86_64/0_README.txt - that file
> clearly highlights the difference in the images, and when one might be
> more suitable than the others.
> 
> The sizes, sha256 sums and torrents for the ISO files:
> 
> * CentOS-7-x86_64-Minimal-1503.iso
>  Size: 591396864
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-15
> 03.torrent
>  sha256sum:
> 0b8482dc7e3076749f7fd914487ec6280539d3ba1f10c5b73c94b632f987f011
> 
> * CentOS-7-x86_64-DVD-1503.iso
>  Size: 4236247040
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1503.t
> orrent
>  sha256sum:
> 1817a1689b3c646a6473c93012e06307c6b659000ccffd188a3f4d0a0b531ba9
> 
> * CentOS-7-x86_64-Everything-1503.iso
>  Size: 7517241344
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Everything
> - -1503.torrent
>  sha256sum:
> 3cef58a3a03aff3ea194e63fdc95f03548b292e6f57e4a931a8d5453a6697661
> 
> * CentOS-7-x86_64-LiveGNOME-1503.iso
>  Size: 1124073472
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveGNOME-
> 1503.torrent
>  sha256sum:
> 2cfc9fab2edb0be51b75ee63528b61cad79489129d2aad1713eeed1b4117ab47
> 
> * CentOS-7-x86_64-LiveKDE-1503.iso
>  Size: 1310720000
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveKDE-15
> 03.torrent
>  sha256sum:
> 6b2cd1c30092e9a141a458d40d0fcba74207b6c80e4f68dc7f800fbe1d7bae1b
> 
> * CentOS-7-x86_64-LiveCD-1503.iso
>  Size: 729808896
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-LiveCD-150
> 3.torrent
>  sha256sum:
> 96ee805573d0617ee11704e7973b55387adef13c6efdc82d50d287dba00dfaf1
> 
> * CentOS-7-x86_64-NetInstall-1503.iso
>  Size: 377487360
>  Torrent:
> http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-NetInstall
> - -1503.torrent
>  sha256sum:
> 498bb78789ddc7973fe14358822eb1b48521bbaca91c17bd132c7f8c903d79b3
> 
> The iso files are also available for direct download from
> http://mirror.centos.org/centos/7/isos/x86_64
> 
> * CentOS 7 1503 Docker Container:  ' docker pull centos' will now
give
> you the 1503 container image. You can see the official CentOS Linux
> container tags at : https://registry.hub.docker.com/_/centos/
> 
> - ----------
> Special Interest Groups
> 
> The CentOS Linux distribution is built, managed, and released by the
> CentOS Core SIG. In addition, we also have the following SIGs that are
> doing an amazing job expanding and building on the base Linux platform:
> 
> * Cloud SIG @ http://wiki.centos.org/SpecialInterestGroup/Cloud is
> working to deliver various cloud controller infrastructure including
> OpenStack. They have a fully functional, feature complete RDO stack
> now available for testing with CentOS Linux 7 at
> http://buildlogs.centos.org/centos/7/cloud/openstack-rdo/
> 
> * Cloud Instance SIG @
> http://wiki.centos.org/SpecialInterestGroup/CloudInstance aims to
> deliver VM images for use in various cloud and virtualised ecosystems
> including AWS (
> https://aws.amazon.com/marketplace/seller-profile?id=16cb8b03-256e-4dde-
> 8f34-1b0f377efe89
> ) and Docker ( https://registry.hub.docker.com/_/centos/ )
> 
> * Virtualization SIG @
> http://wiki.centos.org/SpecialInterestGroup/Virtualization includes
> upstream virtualization and hypervisor related projects including Xen
> ( http://www.xenproject.org ), oVirt ( http://www.ovirt.org/ ), and
> Docker ( http://docker.io ). They also work to build and release
> support tools around these virtualization technologies.
> 
> * Storage SIG @ http://wiki.centos.org/SpecialInterestGroup/Storage
> includes the Gluster Project ( http://www.gluster.org/ ), Ceph (
> http://ceph.com ), OpenAFS ( http://www.openafs.org ) and the SCST
> project ( http://scst.sourceforge.net/ ). Gluster builds for CentOS,
> that track upstream community code are available for testing now at
> http://buildlogs.centos.org/centos/7/storage/gluster/
> 
> * Software Collections SIG @
> http://wiki.centos.org/SpecialInterestGroup/SCLo is working on
> documenting and then delivering software collections built for newer
> versions of in-distro content. Their aim is to deliver a community and
> contributor friendly mechanism for SCL's in an easy to consume format.
> 
> * Atomic SIG @ http://wiki.centos.org/SpecialInterestGroup/Atomic is
> working on building, maintaining, and delivering a CentOS Atomic host
> ( http://projectatomic.io ). Testing and development builds including
> AWS EC2 instances and Vagrant boxes are now available at
> http://wiki.centos.org/SpecialInterestGroup/Atomic/Download
> 
> In addition to these, the CentOS Artwork and CentOS Promo SIGs help
> with promo content and helping organise Dojos around the world.
> 
> SIGs are a great way for people to come together and deliver content
> around a specific area into the wider CentOS ecosystem and we welcome
> groups to come together with low barriers to entry and plenty of
> resources to offer the groups. Details on the process can be found at
> http://wiki.centos.org/SpecialInterestGroup
> 
> - ----------
> Dojo
> 
> We try and organise Dojos in various parts of the world as a one day
> event, to bring together people who use CentOS and others who are keen
> to learn about CentOS. The day's focus is on sharing technical
> knowledge and success stories. It's also a great place to meet and
> talk about upcoming technologies and learn how others are using them
> on CentOS Linux.
> 
> In the coming months we hope to host events in London, Bangalore,
> Sweden, Germany, Spain, and in many parts of the USA. If you would
> like to help organise a Dojo, do drop by the centos-promo list at
> http://lists.centos.org/mailman/listinfo/centos-promo
> 
> - ----------
> Getting Help
> 
> The CentOS ecosystem is sustained by community driven help and
> guidance. The best place to start for new users is at
> http://wiki.centos.org/GettingHelp
> 
> - ----------
> Contributors
> 
> This release was made possible due to the hard work of many people,
> foremost on that list are the Red Hat Engineers for producing a great
> distribution, without them CentOS Linux would look very different.
> 
> We are also looking for people to get involved with the QA process in
> CentOS, if you would like to join this please introduce yourself on
> the centos-devel list (
> http://lists.centos.org/mailman/listinfo/centos-devel ).
> 
> 
> - ----------
> Thanks
> 
> I would also like to thank our donors and sponsors for their continued
> support for the project. And to everyone who contributed with ideas,
> code, test feedback, and promoting CentOS Linux into the ecosystem.
> 
> Enjoy!
> 
> - -- 
> Karanbir Singh, Project Lead, The CentOS Project
> +44-207-0094455 | http://www.centos.org/ | twitter.com/CentOS
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJVGsvBAAoJEI3Oi2Mx7xbt1xAH/0ZoWz65f/O8URzsleO4DaiD
> Wy8YMWaPVTlLDnik7EukYSueT1bE9ziB3DxycQJVXz8HTABdjNugN6Ouy83bCY2a
> 17t6F0VGY0ZRZe6Uqv8rb2xiFnFR/ssy9s921vJVcpzaSLgKl2/D5ed1aSsLaxLw
> CdpYcC7t/8xbkpnCtoyQ2nko0Jzj8fYPr8wCUKTgnf0BXyXYYcuNsi+J6HKzlExc
> KXHuvLDjXCjOVi4X7BLbn2F5N7bwBcmjYWC/hX1oAlD2uvbbNg/+mDbAu9QtWmeC
> RthUq5uwpA05i9MvyMU5/ODS1NpIg3f+JybPLTp9zaFU6hXmJSvOR679wZbFdUc> =Z60w
> -----END PGP SIGNATURE-----
> _______________________________________________
> CentOS-announce mailing list
> CentOS-announce at centos.org
> http://lists.centos.org/mailman/listinfo/centos-announce

On 03/31/2015 09:53 AM, Ryan Qian wrote:
> As a CentOs newbie,  I'm not sure, will we still have CentOS 7.1 which
derive from RHEL 7.1?
> or this is the new naming conversion for CentOS 7.
>
> Thanks!
> -Ryan

That was going to be my question as well.  According to 
http://lists.centos.org/pipermail/centos-announce/2014-July/020393.html 
the convention (for the 7.0 release at least) says:

"Numbering

CentOS 7.0-1406 introduces a new numbering scheme that we want to
further develop into the life of CentOS-7. The 0 component maps to the
upstream realease, whose code this release is built from. The 1406
component indicates the monthstamp of the code included in the release
( in this case, June 2014 ). By using a monthstamp we are able to
respin and reissue updated media for things like container and cloud
images, that are regularly refreshed, while still retaining a
connection to the base distro version."

I would have assumed that this release would be "7.1.1503", and the
URL
on at least one mirror has:

http://mirror.fdcservers.net/centos/7.1.1503/

Guess if that's the new convention, I'll need to keep my ISO files 
sorted out somehow, as this progression isn't intuitive:

CentOS-7.0-1406-x86_64-DVD.iso
CentOS-7-x86_64-DVD-1503.iso

-Greg

On 03/31/2015 11:11 PM, Peter wrote:
> Can you please point me to the centos-devel thread that discussed 
> changing the iso naming convention from CentOS-7.1-1503-x86_64-DVD.iso 
> to CentOS-7-x86_64-DVD-1503.iso? I must have missed it because I saw 
> no mention of this change until today.
The first thread along these lines starts at 
http://lists.centos.org/pipermail/centos-devel/2014-June/010444.html

It is a long thread, as you should know, since you participated in it.

The key post in the thread, in my opinion, is at 
http://lists.centos.org/pipermail/centos-devel/2014-June/010944.html

My takeaway is that the ISO name for 7.1406 was an aberration, and that 
this is the new paradigm going forward.  But I'll also reserve the right 
to be wrong.

On 04/02/2015 03:29 AM, Lamar Owen wrote:
> On 03/31/2015 11:11 PM, Peter wrote:
>> Can you please point me to the centos-devel thread that discussed
>> changing the iso naming convention from CentOS-7.1-1503-x86_64-DVD.iso
>> to CentOS-7-x86_64-DVD-1503.iso? I must have missed it because I saw
>> no mention of this change until today.
> The first thread along these lines starts at
> http://lists.centos.org/pipermail/centos-devel/2014-June/010444.html
> 
> It is a long thread, as you should know, since you participated in it.
Yes I did, which is why I find it strange that making this particular
change to the ISO name format is considered to have come from that
thread.  I don't recall seeing that exact change discussed, but I coudl
be wrong, it was a long thread and I probably didn't read the whole
thing in detail.
> The key post in the thread, in my opinion, is at
> http://lists.centos.org/pipermail/centos-devel/2014-June/010944.html
I still don't see anything in that post about changing the iso name as
mentioned above.  Do feel free to point out specifics to me.
> My takeaway is that the ISO name for 7.1406 was an aberration, and that
> this is the new paradigm going forward.  But I'll also reserve the
right
> to be wrong.
My point is that there was a claim by the board that this particular
change was discussed extensively on the -devel list.  If it was then it
should be quite easy to point out the post(s) in the archives where this
particular discussion tool place.


Peter

On 04/01/2015 03:33 PM, Always Learning wrote:
> If someone (currently anonymous) at Centos says abandon sub-version
> numbers and introduce an illogical ISOs naming structure, a wise person
> will ignore that command.
So, in essence you're saying that the builders of the OS that you use 
and trust for daily tasks are unwise, right?  Sounds to me like you 
might want to use something different.
> just the change will satisfy everyone.
>
>
It is impossible to satisfy everyone.

Le 01/04/2015 22:15, Lamar Owen a ?crit :
> So, in essence you're saying that the builders of the OS that you use 
> and trust for daily tasks are unwise, right?  Sounds to me like you 
> might want to use something different.
>
>> just the change will satisfy everyone.
>>
>>
> It is impossible to satisfy everyone.
So, you refuse to hear your users, who have stated good arguments, for 
something that is not very difficult to change, the name of the iso, 
which is not coherent with the 7.0 name and confusing ? Yes, not very 
wise... Karanbir corrected very quickly the content of the 
redhat-release file, because it was totally different from 7.0, and 
broke a lot of scripts and applications.

Alain

On 04/01/2015 04:43 PM, Alain P?an wrote:
> Le 01/04/2015 22:15, Lamar Owen a ?crit :
>> It is impossible to satisfy everyone.
>
> So, you refuse to hear your users, who have stated good arguments, for 
> something that is not very difficult to change, the name of the iso, 
> which is not coherent with the 7.0 name and confusing ? 
It is only confusing if you let it confuse you.  I've been around this 
thing long enough to remember when the distribution ISO's carried 
wonderful names like 'seawolf-i386-disc1.iso' (study a bit and
you'll
get the joke).  I'm just experiencing a bit of disbelief that people are 
getting hung up over the file's name being the slightest bit 
unexpectedly different, that's all.

And my comment that 'it is impossible to satisfy everyone' is a bit of a
USA idiom, typically quoted as "You can't please anyone all the time, 
nor can you please everyone any time" or similar.
> Yes, not very wise... Karanbir corrected very quickly the content of 
> the redhat-release file, because it was totally different from 7.0, 
> and broke a lot of scripts and applications.
The issue of the content of redhat-release was a serious and valid one 
that actually broke stuff; the ISO name being different from expected 
doesn't break stuff. If the ISO name broke stuff, then that would be 
different, and it would have already been fixed.

On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:
> On 04/01/2015 03:33 PM, Always Learning wrote:
> > If someone (currently anonymous) at Centos says abandon sub-version
> > numbers and introduce an illogical ISOs naming structure, a wise
person
> > will ignore that command.
> 
> So, in essence you're saying that the builders of the OS that you use 
> and trust for daily tasks are unwise, right?  Sounds to me like you 
> might want to use something different.
No I am not as can be conspicuously seen in what I wrote. Lamar your
introduction of non-relevant matters can not detract from the essential
point I made:-

(1) removing sub-version numbers is wrong; and

(2) changing the ISO naming structure from
{major version}-{sub-version}-{build number}-{architecture}-{media}.iso
is an illogical unwise change because anyone looking at 

{major version}-{sub-version}

instantly knows, for example, that is Centos 7.1 whereas

CentOS-7-1503-x86_64-DVD.iso 

is baffling and one is then required to build and maintain a translation
table to convert '1503' into Centos 7.1. That is frankly bonkers.

Creating confusion where there was originally none is essentially silly.

How many times has Johnny and others asserted that Centos is the same as
RHEL ?  More puzzling is the complete absence of logic for this
detrimental removal of the sub-version number.
> It is impossible to satisfy everyone.
I do not remember reading on this list any criticisms of the former, now
abandoned, practise of using:-

{major version}-{sub-version}-{build number}-{architecture}-{media}.iso
 
-- 
Regards,

Paul.
England, EU.      Je suis Charlie.

On Wed, 2015-04-01 at 17:10 -0400, Lamar Owen wrote:
> I'm just experiencing a bit of disbelief that people are 
> getting hung up over the file's name being the slightest bit 
> unexpectedly different, that's all.
1. What is the logically reason for this alleged "improvement" ?

2. How are users of all types, from all around the world, benefiting
from this change ?


R.s.v.p.


-- 
Regards,

Paul.
England, EU.      Je suis Charlie.

On 04/01/2015 08:12 PM, Always Learning wrote:
> 1. What is the logically reason for this alleged "improvement" ?
I never said it was an improvement.  I just said that I didn't think it 
was that big of a deal, and it boggles my mind that people are calling a 
change of an ISO's file name 'unwise' and even comparing it to a 
Microsoft move.  I just don't see it as being that big of a problem.  
Nor do I see it as an improvement.  But the question was asked about 
where such a change might have been discussed, and I pointed to the long 
and drawn out centos-devel thread in which the background for the 
date-based numbering was beaten to death (and beyond).  The CentOS devs 
have stated that the CentOS Board voted on it, and they have the 
decision-making power to do so.  And they are all reasonable people.
> 2. How are users of all types, from all around the world, benefiting
> from this change ?
This change makes it unequivocally clear that CentOS 7.1503 is not 
exactly the same as upstream RHEL 7.1, although it is functionally 
equivalent (where the meaning of functionally equivalent has been hashed 
to death, too, but it basically means binary-compatible but not 
necessarily binary-identical).  Whether you consider that a benefit or 
not is up to you.  I'm personally neutral on the issue.

Consolidating two replies:
On 04/01/2015 07:58 PM, Always Learning wrote:
> On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:
>
>> On 04/01/2015 03:33 PM, Always Learning wrote:
>> (1) removing sub-version numbers is wrong; and ...
That is a matter of opinion.  In my opinion, assigning sub-version 
numbers to what was originally intended to be, by Red Hat, quarterly 
updates (almost Service Packs, if you will, much like SGI's numbering of 
their Foundation and ProPack products for the Altix server line) is what 
is illogical.  Of course, the updates aren't quarterly any more, and 
other aspects of the versioning have morphed and changed over the years 
since the RHAS days (well, even back in certain branches of RHL 6.2, for 
that matter).

So you could read '7.1' as 'version 7 service pack 1.'  My
opinion is
that sub-version numbers give a mistaken impression that the update 
number is a real 'version' when it was not originally so. Further, in 
reality the update number is meaningless for compatibility checks, as it 
is more than possible to have a fully updated CentOS x system that 
claims to be x.0 but has all the packages, save centos-release, of the 
latest x.y; further, it is easily possible to install the CentOS x.6 
centos-release package on a completely unpatched x.0 system, making the 
contents of andy of the /etc/*-release files not terribly useful for 
strict versioning.

It is my opinion, although it's not a vehement opinion, that beginning 
the x.y practice is what was illogical.  But it was done, and it is 
over, and I have more important things to do than gripe over semantics 
such as that.
> Creating confusion where there was originally none is essentially silly.
I am not so easily confused by the new numbering; what the ISO is named 
is orthogonal to what it contains, at least in my mind.
> How many times has Johnny and others asserted that Centos is the same as
> RHEL ?
The assertion is that CentOS is functionally equivalent to the upstream 
product.  It is not 'the same as' nor can it be and still remove the 
trademarked branding of the upstream release.  It is binary compatible 
without being binary identical. And as the meaning of 'binary 
compatible' has also been hashed to death, I'll not further clutter the 
traffic on this list about what it means.  It's easy enough to read the 
centos-devel archives to see for yourself.

On Wed, Apr 1, 2015 at 11:51 PM, Lamar Owen <lowen at pari.edu>
wrote:
>>
> I am not so easily confused by the new numbering; what the ISO is named is
> orthogonal to what it contains, at least in my mind.
Adding the date component means CentOS may release more than one iso
per RH's minor versions.  There isn't much of a consistent
relationship between the RH release and the subsequent Centos release
other than 'sometime later when it is ready'.   So, given a set of
Centos isos or even just the most recent, how would you know which RH
release it is based on?  Download, install, and read the
/etc/os-release file before finding out?   Or look up some other
source of the missing information?

-- 
  Les Mikesell
    lesmiksesell at gmail.com

On 04/02/2015 01:12 AM, Les Mikesell wrote:
> Adding the date component means CentOS may release more than one iso 
> per RH's minor versions. 
Newsflash: they already are, just not in the main releases trees. Look 
in http://buildlogs.centos.org/rolling/7/isos/x86_64/

I previously used the 20150228 CentOS 7 rolling Everything ISO to do a 
reinstall; worked great.  Nice to not have to grab hundreds of MB of 
updates right out of the box.  This was on the CentOS-Announce list, 
incidentally.
> There isn't much of a consistent relationship between the RH release 
> and the subsequent Centos release other than 'sometime later when it 
> is ready'. So, given a set of Centos isos or even just the most 
> recent, how would you know which RH release it is based on? 
Hmm, maybe the name of the directory it is in and the link in the 
release notes?  I also notice that the rolling point in time images have 
the full four digit year as well as month and day, whereas the 
'functionally equivalent to a particular Red Hat update release' image 
has a two digit year, the month, but no day.

On 04/02/2015 01:12 AM, Les Mikesell wrote:
> So, given a set of
> Centos isos or even just the most recent, how would you know which RH
> release it is based on?
Oh, one more minor point, and I know I'm probably in the minority here: 
for most of the cases where I use CentOS, I don't actually care which 
RHEL release it is 'based on.'  I just want 'latest CentOS
[567]' for
95% of my uses.  Well, 5 not as much now, but definitely 6 and 7.  I 
actually don't even have a case in production right now that is strict 
release-number-bound, but I did have a couple at one point.

So I don't care which update the CentOS ISO most closely corresponds 
with; it's CentOS, and the software I need to have work works, since it 
either works with or will soon work with latest RHEL.  (the Dell 
Poweredge stuff, for instance, where I'm 100% fully updated CentOS 6 at 
the moment).  Updates of course get vetted in testing first, but I try 
to not rely on software that is 
update-point-release-strict-number-bound.  And if I were to need that 
kind of strict release number binding, that particular machine would 
probably get Scientific Linux installed, since they do backports of 
certain things to earlier releases and let you stay at a particular 
update level while getting certain other updates. Although there are 
changes in RHEL 7.1 that are challenging things in that respect; see the 
threads on the SL lists related to SL7x and EPEL, for instance.

Of course, you can always trick out a release number bound setup by 
forcing a particular centos-release package to be the one that is 
installed, if it is a 'paper' requirement rather than a real requirement
(which I have run into before).

But I know others have other requirements; YMMV and all that.  I'm just 
stating what the reality is for my uses at the moment.

On Thu, 2015-04-02 at 00:51 -0400, Lamar Owen wrote:
> Nor do I see it as an improvement.
Thank you for your considered response. If it is not an improvement,
then there is no reason for the change, is there ?
> In my opinion, assigning sub-version numbers to what was originally
>  intended to be, by Red Hat, quarterly updates (almost Service Packs,
>  if you will, much like SGI's numbering of their Foundation and ProPack
>  products for the Altix server line) is what is illogical.  Of course,
>  the updates aren't quarterly any more, and other aspects of the
>  versioning have morphed and changed over the years since the RHAS days
>  (well, even back in certain branches of RHL 6.2, for that matter).
Whatever the original cause introducing sub-version numbering, that
usage has become a clear progressive indicator of collections of updates
within the major version.  
> in reality the update number is meaningless for compatibility checks,
>  as it is more than possible to have a fully updated CentOS x system
>  that claims to be x.0 but has all the packages, save centos-release,
>  of the latest x.y; further, it is easily possible to install the
>  CentOS x.6 centos-release package on a completely unpatched x.0
>  system, making the contents of andy of the /etc/*-release files not
>  terribly useful for strict versioning.
I image the vast majority of Centos users will not risk doing
non-standard updates on their production systems so your above concern
is unlikely to occur.
> > Creating confusion where there was originally none is essentially
silly.
> 
> I am not so easily confused by the new numbering;
I can not look at something labelled Centos 7.2169 and instantly know if
it is Centos 7.1, 7.5 or even Centos 7.10.  What's the latest version of
Centos 6 ?  Is it 6.32167 or 6.32782 or 6.32783 or should I be typing
6.23783 instead ? Confusion is not clarity.

> > How many times has Johnny and others asserted that Centos is the same
as
> > RHEL ?
> The assertion is that CentOS is functionally equivalent to the upstream 
> product.
If Centos is "functionally equivalent" to RHEL then common sense must
dictate that the sub-version numbers should be compatible too.


-- 
Regards,

Paul.
England, EU.      Je suis Charlie.

On 04/02/15 00:51, Lamar Owen wrote:
> On 04/01/2015 08:12 PM, Always Learning wrote:
>> 1. What is the logically reason for this alleged
"improvement" ?
>
> I never said it was an improvement.  I just said that I didn't think it
was
> that big of a deal, and it boggles my mind that people are calling a change
of
> an ISO's file name 'unwise' and even comparing it to a
Microsoft move.  I just
> don't see it as being that big of a problem. Nor do I see it as an
> improvement.  But the question was asked about where such a change might
have
> been discussed, and I pointed to the long and drawn out centos-devel thread
in
> which the background for the date-based numbering was beaten to death (and
> beyond).  The CentOS devs have stated that the CentOS Board voted on it,
and
> they have the decision-making power to do so.  And they are all reasonable
> people.
But only those on the devel list ever saw the discussion. Those of us whose 
job it is to be sysadmins, and run many systems, don't tend to be on that
list
also.

Had you, for example, made it release.subrelease.date (7.1.1503), it would 
have been less disruptive and annoying.

	mark
>
>> 2. How are users of all types, from all around the world, benefiting
>> from this change ?
> This change makes it unequivocally clear that CentOS 7.1503 is not exactly
the
> same as upstream RHEL 7.1, although it is functionally equivalent (where
the
> meaning of functionally equivalent has been hashed to death, too, but it
> basically means binary-compatible but not necessarily binary-identical).
> Whether you consider that a benefit or not is up to you.  I'm
personally
> neutral on the issue.
>
> Consolidating two replies:
> On 04/01/2015 07:58 PM, Always Learning wrote:
>> On Wed, 2015-04-01 at 16:15 -0400, Lamar Owen wrote:
>>
>>> On 04/01/2015 03:33 PM, Always Learning wrote:
>>> (1) removing sub-version numbers is wrong; and ...
>
> That is a matter of opinion.  In my opinion, assigning sub-version numbers
to
> what was originally intended to be, by Red Hat, quarterly updates (almost
> Service Packs, if you will, much like SGI's numbering of their
Foundation and
> ProPack products for the Altix server line) is what is illogical.  Of
course,
> the updates aren't quarterly any more, and other aspects of the
versioning
> have morphed and changed over the years since the RHAS days (well, even
back
> in certain branches of RHL 6.2, for that matter).
>
> So you could read '7.1' as 'version 7 service pack 1.'  My
opinion is that
> sub-version numbers give a mistaken impression that the update number is a
> real 'version' when it was not originally so. Further, in reality
the update
> number is meaningless for compatibility checks, as it is more than possible
to
> have a fully updated CentOS x system that claims to be x.0 but has all the
> packages, save centos-release, of the latest x.y; further, it is easily
> possible to install the CentOS x.6 centos-release package on a completely
> unpatched x.0 system, making the contents of andy of the /etc/*-release
files
> not terribly useful for strict versioning.
>
> It is my opinion, although it's not a vehement opinion, that beginning
the x.y
> practice is what was illogical.  But it was done, and it is over, and I
have
> more important things to do than gripe over semantics such as that.
>
>> Creating confusion where there was originally none is essentially
silly.
>
> I am not so easily confused by the new numbering; what the ISO is named is
> orthogonal to what it contains, at least in my mind.
>
>> How many times has Johnny and others asserted that Centos is the same
as
>> RHEL ?
> The assertion is that CentOS is functionally equivalent to the upstream
> product.  It is not 'the same as' nor can it be and still remove
the
> trademarked branding of the upstream release.  It is binary compatible
without
> being binary identical. And as the meaning of 'binary compatible'
has also
> been hashed to death, I'll not further clutter the traffic on this list
about
> what it means.  It's easy enough to read the centos-devel archives to
see for
> yourself.
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

On 04/02/2015 10:59 AM, Phelps, Matthew wrote:
> It's not just the name of the ISO file. c.f. the VERSION_ID variable in
> /etc/os-release
In that particular place it is actually rather important, but that is 
orthogonal to the ISO name.

On Thu, Apr 2, 2015 at 11:19 AM, Lamar Owen <lowen at pari.edu> wrote:
> On 04/02/2015 10:59 AM, Phelps, Matthew wrote:
>
>> It's not just the name of the ISO file. c.f. the VERSION_ID
variable in
>> /etc/os-release
>>
> In that particular place it is actually rather important, but that is
> orthogonal to the ISO name.
>
>
I agree, but this thread started off with a more general discussion of
release/version numbering.

-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu

On 04/01/2015 10:10 PM, Lamar Owen wrote:
>> Yes, not very wise... Karanbir corrected very quickly the content of
>> the redhat-release file, because it was totally different from 7.0,
>> and broke a lot of scripts and applications.
> The issue of the content of redhat-release was a serious and valid one
> that actually broke stuff; the ISO name being different from expected
> doesn't break stuff. If the ISO name broke stuff, then that would be
> different, and it would have already been fixed.
This is the key bit here - were not trying to break anything - we are
trying to keep things sane for folks who are already invested in the
platform while also allowing other people to do interesting things.

You brought up the rolling builds, and yes - we've been doing it. Its
been immense value ( over 100K downloads for the 2015 Feb builds as a
point of reference ). for other process's like the Atomic builds,
needing the nightly, weekly builds has been key to their ability to get
the technology moving. There are a lot of such examples around, but I
will admit many of them are silo'd away slightly from this list - eg.
the docker traction we have does not typically feedback here to this
list and perhaps not into this audience. But should you want to move
into container space, CentOS today represents one of the best all around
experiences either on host or instance side.

The story is similar on the Cloud side of things, we have a ver large
cloud instance base - if i were to fancy a guess, I'd say 20% of the
centos install base is today in cloud ( and this is largely only
offprem, including onprem the numbers might go higher, but there is no
way to tell since they could just be real machine instances ).

Putting all that aside, the baseline assumption that we should all be
mindful of is that in real terms there is no CentOS point release : any
centos install, regardless of where it originated from, yum updated to
the same point in time will have the same package manifest, and should
deliver the same feature set ( with some exceptions, like environ
specific workloads might have local flavour - you wouldnt expect cups on
an GCE instance for example ).

So what the changesets have done ( and lets be fair, these changes like
the iso name changing to line up a date stream rather an an arbitary
point in time isnt a huge deal, you can just rename the file locally if
you so wish ), effectively line up and help deliver on that.

Let me highlight this with two examples:
- the Amazon instances we provide  have been updated out of band, to
cover for the security issues that have wider impact, heartbleed and
poodle and all that stuff : labelling those as 7.0 makes no sense since
it does not deliver on a 7.0 feature set, it delivers a CentOS-7/Dec
2014 update set.

- Second example is that when you look at a machine and it says 5.5 its
hard to explain to the user that his machine might be 5 years out of
date, there is a baseline cultural expectation that a release is either
maintained or not - and having the conversations around CentOS-5 being
maintained but not 5.5 isnt easy. Remember that this list represents the
folks who really know, and know well, both the ecosystem and platform as
well as their workloads and userbase - there are a lot ( a majority ? )
of CentOS user who dont get this. For them to line up with a
CentOS-7/2014-06 and CentOS-7/2015-03 immediately makes sense. it makes
it easier for us to communicate the delta in security and bugfix that
they dont have on there.

And I think the overall solution we have in place right now, really does
this well in that we clearly communicate the upstream relationship,
while still being able to deliver the common message on and around the
centos-release spec. If there are tangiable situations where this change
causes harm, then I am very willing to reach out and help find a
solution : dont want to break existing installs nor reduce the info
available.

The other thing here in this conversation is also that there is a large
emotional resistance to change. Folks expect the numbers to line up in a
specific manner, and they dont - the contents of the images however
still give you the metadata you need ( both ways, they should give you
point in time, and release from rhel that we derived/built from ).

Happy to pickup and work through individual concerns people might have
around this. But in real terms, please note that there is no change in
the content being delivered. We are only opening up options to line up
various media and point-in-time images.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc