Phil Schaffner wrote:
> Well, how about backing up to the basic assumptions
before suggesting
> solutions. Just because the upstream with their much
greater (paid)
> resources seem to be going to a M.N release scheme, is
CentOS
> constrained to follow precisely in their footsteps?
maybe, or maybe not. the issue here is that if VAR Mr.$X
only supports a product
on 5.3.1 and CentOS does not provide that, there is a
problem. The landscape is
littered with people / vendors / support people only
recommending people stick
within a specific release Update version ( which might be
one of the driving
forces behind upstreams decision to create this sub-release
thing in the first
place ).
> What's wrong with
> keeping the current scheme of following the latest
release and
> continuing to have M as a pointer to the latest M.N
tree? If someone
> REALLY needs the minor release[es] with associated
updates, they can go
> to the upstream for support; however, I suspect that
would be a
> relatively rare case. If the demand is there down the
road, can always
> re-evaluate the policy.
ok, so for now - lets assume that we will not be doing the
sub-release [1], then
what can we do now to make sure that we provision in the
ability to make this
call at a later stage ?
[1] although, if it happens upstream there will be a lot of
people asking for it
within CentOS as well, and to be honest - as long as we can,
we should.
--
Karanbir Singh : http://www.karan.org/ :
2522219 icq
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel
|
