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.