On Fri, Dec 04, 2015 at 12:24:23AM +0100, Leon Fauster wrote:
> Am 03.12.2015 um 22:24 schrieb "Phelps, Matthew" <mphe...@cfa.harvard.edu>:
> > Why the change now? It really does matter, a lot, to those of us who need
> > to do compliance testing/security checks, etc. all based on "version"
> > number. I know there is no such thing in practice because of all the
> > non-sequential updates that happen, but there's a shit-ton of work that we
> > have to do for each new release, and we have depended in the past on the
> > versions matching the RHEL ones. Now, they don't, and that's wrong.
> >
> > It seems like a minor thing, but in real-world practice it is most
> > definitely not.
>
> As stated by others - this provisioning concept never was supported by CentOS.
"never was supported"? But it has been used by software vendors! My
startup PathScale supported CentOS for both our MPI interconnect
libraries and our compilers. Our scripts opened up
/etc/{centos,redhat}-release and parsed what was inside. And that
worked great since 2004, and it would work today with minor hassle,
because the centos version string in there is 7.1.1503... quite
similar to 7.1.
I feel sorry for my former colleagues, now at Intel, having to pollute
their docs and code for an unnecessarily confused scheme, getting to
deal with customers who become confused when you use the new scheme
and they're still referring to it by the old one, or vice versa.
-- greg
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
