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 >