From a Debian & Ubuntu point-of-view, the version numbering does have an implied meaning.
Take 1.0.0
"1" is project specific - i.e. it is the project that decides when a release is big enough to warrant a whole number change
"1.x" - the x here means there are sufficient changes such as new capability/ABI/API bumps. After a feature freeze the "x" here means that Debian/Ubuntu wouldn't normally take a new version without a "release request" - can be quite involved to-do this and is generally frowned upon.
"1.x.y" - the y here means it is basically a bug fix. i.e. doesn't introduce new capability - just fixes something(s) that is (are) broken.
end of missive
The point of this issue - I personally would consider the 100+commits introduced since v1.010 quite a bit of new capability and hence I would support a v1.1.0 release if at all possible?
I note however, that you have tagged various issues as 1.0.11
Hi,
quick missive for future version numbering.
From a Debian & Ubuntu point-of-view, the version numbering does have an implied meaning.
Take 1.0.0
"1" is project specific - i.e. it is the project that decides when a release is big enough to warrant a whole number change "1.x" - the x here means there are sufficient changes such as new capability/ABI/API bumps. After a feature freeze the "x" here means that Debian/Ubuntu wouldn't normally take a new version without a "release request" - can be quite involved to-do this and is generally frowned upon. "1.x.y" - the y here means it is basically a bug fix. i.e. doesn't introduce new capability - just fixes something(s) that is (are) broken.
end of missive
The point of this issue - I personally would consider the 100+commits introduced since v1.010 quite a bit of new capability and hence I would support a v1.1.0 release if at all possible?
I note however, that you have tagged various issues as 1.0.11