On 2013-08-27 10:02 Roland Kaufmann wrote:
The "version" should be increased in a semantically coherent
manner, (see e.g. http://semver.org) whereas the "label" can be
whatever we wants.
So actually, we should argue about what the version number should
increase to after release branching. :-)
On 2013-08-27 12:23, Andreas Lauser wrote:
yeah, probably. I find the "one version for the aggregate release,
another for the API version" scheme quite confusing BTW. Probably we
should use the <yyyy>.<mm> scheme for the libraries, too.
There is a problem with this: Is 2013.09 compatible with 2013.03? You
cannot really tell from the numbers, whereas 1.1 is expected to be
compatible with 1.0, but 2.0 is not. On the other hand, a version number
like 13.2 doesn't convey any information about the state of the project
in itself.
Thus, there is one set of versions for determining technical API
compatibility, and one set to determine social maturity.
And the former could be advanced when we branch off to another release,
but it cannot contain a string. Using a high number is OK, but then
you'll have to decide if you want to make non-breaking changes (1.1
cannot follow 1.99, and 1.0.99 is not necessarily better stability-wise
than 1.0.1); sometimes odd/even numbers in the minor are used to
indicate stable/unstable.
--
Roland.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
