<p dir="ltr"><br>
On Jun 21, 2014 1:42 PM, "Johnny Hughes" <<a href="mailto:johnny@centos.org">johnny@centos.org</a>> wrote:<br>
><br>
> On 06/21/2014 05:00 AM, Ron Yorston wrote:<br>
> > Johnny Hughes wrote:<br>
> >> What better way to communicate that they are not standalone but are all<br>
> >> only part of the MAJOR release and a POINT IN TIME part of that major<br>
> >> release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?<br>
> > The current scheme represents <POINT IN TIME> as an integer that starts<br>
> > from zero and increments with each minor release.<br>
> ><br>
> > I remain unconvinced that a YYMM representation of <POINT IN TIME> is<br>
> > any better.<br>
><br>
> It is not really better at conveying time, no. It is the same at<br>
> conveying the time.<br>
><br>
> Where it is better is in denoting that Red Hat is doing things inside<br>
> the 6.4 tree (again, just following the above example) while CentOS does<br>
> not do those things inside our 6.4 tree after we release 6.5. We can't<br>
> do them, even if we want to as we don't have the sources.<br>
></p>
<p dir="ltr">Why we don't have the sources? Isn't Red Hat obliged to give the sources with the binary packages? <br></p>
<p dir="ltr">> That is my whole point .. we need a way to convey a similarity and one<br>
> point, while not being similar always. Having the exact same name does<br>
> not convey that.<br>
><br>
> How do you suggest we do that and not ignore that there are potential<br>
> differences after we move to the next point release? Do we just ignore<br>
> that part?<br>
><br>
> Everything on this list that is newer than 2013-11-20 is in the RHEL 6.4<br>
> tree ... we don't and can't release any of it for our 6.4:<br>
><br>
> <a href="https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html">https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html</a><br>
><br>
> So our 6.4 tree is now significantly divergent from the Red Hat 6.4<br>
> tree, and our 6.4 tree is in the vault and not live anymore ... don't we<br>
> have an obligation to our users to make sure they understand that there<br>
> are differences?<br>
><br>
> UserA has some software that only works with 6.4 .. he sees CentOS-6.4<br>
> in the vault and grabs that to use with his software. He can't upgrade<br>
> to 6.5 because it will break his software. Staying on our 6.4 tree will<br>
> leave UserA vulnerable with security issues. If he is instead on the<br>
> Red Hat 6.4 tree, he is still going to be able to get updates. Do we<br>
> not have any obligation to change our numbering so that UserA can more<br>
> easily tell this hugely major difference?<br>
><br>
> We don't really have the upstream point releases, we have different<br>
> point releases. We release the main line CentOS-5, CentOS-6, and<br>
> CentOS-7 ... we do point in time respins of ISOs and install trees, Red<br>
> Hat does all this and a bunch more things also inside point releases.<br>
> These two things are not EXACTLY the same ever, but they are very<br>
> similar for one 6 to 8 month "period of time" (while they are OUR active<br>
> release and Red Hat's active release) and they become increasing<br>
> divergent after that point in time. That is what I am trying to convey<br>
> here. Some people will argue that people have to pay for that other REd<br>
> Hat 6.4 tree ... sure they do. They also have to pay the initial Red<br>
> Hat 6.4 tree, they have to pay for everything there, thats how it works.<br>
><br>
> Everyone here thinks that we should just leave the point releases as is,<br>
> knowing that now Red Hat is doing completely different things inside<br>
> point releases and that we don't have an obligation to point out the<br>
> differences?<br>
><br>
><br>
> _______________________________________________<br>
> CentOS-devel mailing list<br>
> <a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
> <a href="http://lists.centos.org/mailman/listinfo/centos-devel">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
><br>
</p>