> > >> 1. Usually more condensed than the pre-release. >> 2. Some projects experience multiple "releases" with the same version >> of software (1.0.0-2). >> 3. Libjpeg and OpenSSL use a single letter to represent a level of >> security for some software (1.0.0g). >> >> openssl actually use a multi-letter suffix once it gets high enough. The > next version of openssl 0.9.8 will be 0.9.8za. >
>From what I have found, there are some key words that can be used to identify if a suffix is a pre-release (alpha, beta, ...). I would propose that the existence of these words be used to identify this suffix but still perform the compare lexicographically. Also, we should not support the abbreviated forms since the abbreviated forms collide with single letter release suffix. Since the checking for the existence for some keywords could be expensive, I was thinking about checking for the words when the suffix is being set and not in the compare operation itself. This would allow for multiple compares to occur without the overhead of rechecking the same string. For release versions, I cannot determine any notation that clearly defines a release suffix other than not containing the list of keywords mentioned above. Other comparison rules: 1. Numerical groupings should be compared integers instead of characters in order to properly allow for "alpha2" < "alpha11". 2. Delimiters should only be used to denote groups of content but be skipped during the compare. "alpha" == "-alpha" == "~alpha" == ".alpha" 1. Can be restricted to the first character if this is too broad. Here is an opinion that I think should be made a rule: lexicographical compares should be case insensitive. I don't know of any projects that use case to denote a specific version but I have seen case change for the same version. The biggest example is "rc" where it has been "RC" in some documentation but delivered as "rc". I think this would be a good idea, but changing it to case sensitive would be trivial.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development