Hi, On Monday 26 August 2013 13:38:11 Atgeirr Rasmussen wrote: > Den 26. aug. 2013 kl. 15:24 skrev Andreas Lauser: > > this issue appeared in PR 335 for opm-core, but it is a more "political" > > problem, so I push it to the mailing list: What version should be used for > > the master branches? As far as I can see, there are three alternatives: > > > > (1) keep the version number of the previous release for the master branch. > > That's the current OPM approach > > (2) after a release, immediately increase the version number of the master > > branch to the one of the next release (the current Dune approach) > > (3) after a release, use the version that release for the development > > branch, but increment the point release level to something > > unrealistically high for the normal maintenance releases (99, say). This > > is the approach KDE takes. > > > > Since (1) and (2) come with severe compatibility issues which are hard to > > spot, I'm inclined to (3), but this is approach also has some conceptual > > impurities (i.e., misuse of the point release level)… > > 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?
well, the problem is that strings are hard to check in the code. AFAIK there is no possibility to compare them in the preprocessor, so #if OPM_IS_NEWER_THAN(2013,03) // ... #endif won't work... > For example: 2013.09-nextrelease > > Otherwise, I think what we do now (1) would be the least confusing. 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. (with option (2) the confusion at least only happens if the person uses an 'intermediate version', i.e. they did not update their local copy after the next release.) 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
