Martin Lucina wrote: > [email protected] said: >>> #define LIBEVENT_VERSION_NUMBER 0x02000300 >>> #define LIBEVENT_VERSION "0.2.0.3-alpha" >>> *const* *char* *event_get_version(*void*); >>> ev_uint32_t event_get_version_number(*void*); >>> >>> >>> Provide #defines for compile time checks, numeric function for runtime >>> check, and string for informative display. >>> >>> This means you will should to keep the micro version number rolling >>> along with whatever version suffixes you wish to use. >> This seems to make sense. Any complaints, anyone? > > Oh no, yet another version numbering discussion! :-) > > My 2c: > > - The tuple syntax for programatically comparing version numbers is much > cleaner as opposed to anything using strings. > > - "Alpha", "Beta" and so on are really just labels to the user, so I would > prefer an approach that decouples these from actual version number > checks. (Rationale: Language binding X does not care if the core is > Alpha, Beta or something else, only if the ABI provides Y) > > If I were making the decision I'd go with plain old MAJOR.MINOR.PATCH, use > tuples, and have "Alpha", "Beta", "Now with Pengiuns" simply as labels on > the website download page.
2.0-alpha1 = 2.0.0 2.0-alpha2 = 2.0.1 2.0-alpha3 = 2.0.2 2.0-beta1 = 2.0.3 etc. Right? How does this map to library version numbering? Would 0MQ/2.0.52 produce libzmq.so.2.0.52 ? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
