Hi, On Tuesday 27 August 2013 14:04:23 Roland Kaufmann wrote: > 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.
I see. One question, though: do we make any ABI compatibility guarantees between releases? Currently this is not the case, AFAICS... cheers Andreas -- A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he -- Davidlohr Bueso
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
