On 11/16/11 4:43 PM, "Arun C Murthy" <[email protected]> wrote: > I propose we adopt the convention that a new major version should be a > superset of the previous major version, features-wise. Just so I'm clear. This is only guaranteed at the time the new major version is started. A day later a previous major line may merge a feature from trunk and then it's no longer the case that 2.x.y is a superset. If that's the case I'm not sure of the value of the convention. We could say that new major versions always start from trunk, but that doesn't have meaning outside of the developer community.
On Nov 16, 2011, at 3:02 PM, Doug Cutting wrote: > > Another definition is that a major release permits incompatible changes, > either in APIs, wire-formats, on-disk formats, etc. Are our wire formats stable enough in all release lines that we're ready to live by this? It would mean the 1.x.y line could not change a wire format without a bump to the major number, which would obviously cause issues. Even in the 23.x line I thought there were still some wire compatibility changes pending which would mean we'd quickly be moving to a 4.x line. Nathan
