On 05/09/2016 03:18 PM, Darren Duncan wrote:
> Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
> optionally more. MAJOR must be increased when a backwards-compatibility
> break is made of any kind (such as removing a feature), otherwise MINOR
> must be increased for any forwards-compatibility break (such as adding a
> feature), otherwise PATCH must be increased for changes that shouldn't
> break any kind of compatibility, except for fixing bugs or security
> holes where the old behavior was not being relied on for any working
> uses. MATURITY means eg alpha/beta/rc/production etc.
That seems like that would be an argument against 10.0? Since we didn't
break backwards compat?
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)