[CentOS-devel] CentOS 7 and release numbering

On 06/20/2014 06:23 AM, Manuel Wolfshant wrote:
> On 06/20/2014 02:15 PM, Johnny Hughes wrote:
>> On 06/20/2014 06:06 AM, Tim Bell wrote:
>>>> -----Original Message-----
>>>> From: centos-devel-bounces at centos.org [mailto:centos-devel-
>>>> bounces at centos.org] On Behalf Of Greg Lindahl
>>>> Sent: 20 June 2014 12:53
>>>> To: The CentOS developers mailing list.
>>>> Subject: Re: [CentOS-devel] CentOS 7 and release numbering
>>>>
>>>> On Fri, Jun 20, 2014 at 11:35:08AM +0100, Karanbir Singh wrote:
>>>>
>>>>> I'm also assuming that my last email to this thread cleared all the
>>>>> technical issues that people had brought up, if there are still some
>>>>> outstanding now is a great time for people to raise those.
>>>> I read it, and I'm still 'meh' on the concept. I think that there should be a
>>>> compelling reason to diverge from upstream versioning, and I don't see it.
>>>>
>>>> The SIG problem is that either SIGs are at the tip, or not. Having different version
>>>> names from upstream doesn't really help.
>>>>
>>>> The user problem is that either users are at the tip, or not. Having different
>>>> version names might make that more obvious, but I bet that people who don't
>>>> stay at the tip won't notice.
>>>>
>>>> I stay at the tip.  Having different version numbers from upstream merely
>>>> confuses my coworkers. Hence, 'meh'.
>>>>
>>>> -- greg
>>>>
>>> I share Greg's perspective. I see the technical arguments but have not seen the benefits that justify the significant confusion.
>>>
>>> The communication problems you raise are exactly the ones that we will have with our user community. Given the difficulties you have explaining it to those on centos-devel, imagine how we'll be explaining it to our thousands of users, external support lines and management chains.
>>>
>>> I could explain a 7.0 or even 7.0.1406 but a 7.1406 with an associated wiki page would cause us real problems in the field.
>>>
>> You think it is much easier to explain a data breach costing your client
>> in the field millions dollars because someone THOUGHT they had 7.1 EUS
>> and all its security updates, just like RHEL has, when the tree is at
>> 7.3?  We need to prevent people from thinking is OK to stay on an old
>> tree, it absolutely is not.
>>
> adding mere digits to the name will not help in any way. as far as I 
> have seen in #centos, most of those who do not update stay at a 
> particular version in time because they do do not WANT to update not 
> because they are not familiar with the concept or the need to update. 
> "it works as it is, we are afrain that an update might break something". 
> what most are not familiar with are unchanged ABI and backports. But 
> changing the naming scheme will not help with that in any way.

I'll try to explain this in a different way.

The goal that we have, and have always had, in CentOS is rebuilding the
RHEL Sources and maintaining bug for bug complete compatibly with a
specific RHEL branch.  That specific RHEL branch is the MAJOR branch. 
Major being el3, el4, el5, el6, el7, etc.

When RHEL first started doing updated branches, they had one branch and
they did updates to it .. they called it RHEL 3 and the updates were
RHEL 3 update 3.  We (the CentOS Project) called it 3.3.  The dot or
point release signified a point in time release and was not to be used
in any way other than to signify at that exact point in time, we had
some relation to the upstream source code.

As you can see, in that case we were PURPOSELY different from RHEL's
numbering .. because RHEL was doing other things besides just the update
3 in their 3 branch.  We did not want to confuse our users into thinking
we were doing all the things in the 3 branch ... we were doing one thing
and doing that one thing well ... maintaining a el3 tree.

Red Hat then changed and adopted OUR numbering scheme for RHEL.

The fact of the matter is, that our point releases are NOT the same as
the RHEL point releases ... they are doing much more things inside the
point release trees than we are (now, just like before).

It seems ALL our users are confused and think our releases have a
complete and ironclad direct relationship to the exact point release
upstream .. they have the same number, they must be the same, right?

The issue here is that they are not the same and we (the CentOS Project)
have an obligation to communicate that to our users.  Our updates are
just a point in time snapshot of the main line MAJOR tree ... that is
what they are now and what they always have been.  It is all about the
/7/ and not about the point.

What better way to communicate that they are not standalone but are all
only part of the MAJOR release and a POINT IN TIME part of that major
release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140620/77d88287/attachment-0003.sig>