Hi All, On Tuesday 27 August 2013 10:02:27 Roland Kaufmann wrote: > On 2013-08-26 13:38, Atgeirr Rasmussen wrote: > >> Our version numbers are more like strings than number sets, so can > >> we use something like (3) with a string instead of a large number? > > On 2013-08-26 15:49, Andreas Lauser wrote: > > well, the problem is that strings are hard to check in the code. > > AFAIK there is no possibility to compare them in the preprocessor, > > > > #if OPM_IS_NEWER_THAN(2013,03) // ... > > > > #endif > > > > won't work... > > Don't do this. Do instead: > > #include <opm/core/version.h> > > #if DUNE_VERSION_NEWER(OPM_CORE, 1, 0) > // ... > #endif > > Much more stable. The "version" should be increased in a semantically > coherent manner, (see e.g. http://semver.org) whereas the "label" can be > whatever we wants.
You are (of course) right. that was rather meant as an example which is hard or impossible to implement using strings... > So actually, we should argue about what the version number should > increase to after release branching. :-) 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. (possibly suffixed by a point release level.) > > hm, what happens if something regresses the master branch, and the > > person affected sends his log (which says that the version is the one > > of the last release)? I at least would be totally confused. > > Never trust anything other than the "Source code repository:" line in > the configuration log. And pay attention to whether there is a star > suffix (meaning: local changes). okay, thanks for the hint. would you mind putting this info into the wiki? (of course only once you have a silent hour.) 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 [email protected] http://www.opm-project.org/mailman/listinfo/opm
