On 02/13/2014 10:51 AM, A.L.M.Buxey@lboro.ac.uk wrote:
NAK to removing them in 3.1, you shouldn't remove features in a minor point release. I would suggest postponing such a change to the next major release, 4.0.
3.0 - 3.1 isnt a minor point release - major changes between the 2.
3.0.1 - 3.0.2 is a minor point release
(I'll cite the openssl 0.9.x -> 0.9.y patch as previous precendent ;-) )
Sigh, everyone uses different terminology [1] and the mistakes committed by other projects do not provide justification. Here's the short story: Red Hat policy is incompatible configuration changes can only occur when a package major version changes. We do not permit package major version changes to occur in any given distribution (e.g. RHEL-6, RHEL-7, Fedora 19, etc.) otherwise applying a distribution update could break an otherwise properly running system by introducing incompatible configuration, especially because updates are frequently applied automatically. This is a sane release engineering policy. Applying a package update must never break a system. Migration to a new distribution is the moment at which admins are on alert for significant changes they must pro-actively react to. [1] The terminology we use and I'm familiar with is [2]: Numbers are separated by dots. Major is first number. Minor is second number. Bug fix is third number. So in my world 3.0 -> 3.1 is a minor version change, the major number is the same but the minor number has been incremented (thus you cannot delete functionality [3]). [2] These are how upstream versions are interpreted. RPM nvr's (name-version-release) is something else, where the v for version is identically the upstream version and the r for release is a distribution specific increment usually used for distribution specific patches to upstream or rebuilds. [3] Adding functionality in a configuration compatible manner is permissible. -- John