http://bugzilla.wpkg.org/show_bug.cgi?id=120
Rainer Meier <r.me...@wpkg.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #149 is|0 |1
obsolete| |
--- Comment #14 from Rainer Meier <r.me...@wpkg.org> 2009-06-16 00:01:43 ---
Created an attachment (id=150)
--> (http://bugzilla.wpkg.org/attachment.cgi?id=150)
New version comparison algorithm for testing.
> Never heard of "Integration", but things like "1.0b5", "1.0beta5", "1.0_beta5"
> etc come to mind. same goes for alpha.
OK, I guess we will never be able to cover all cases. Moreover I don't like
this "blacklist" approach too much because as the list grows the result of a
version comparison gets less and less deterministic.
So for the moment the list of "volatile-version-markers" include:
- rc
- i
- m
- alpha
- beta
- pre
- prerelease
Whatever version you use there will always be a way to create a new version
which evaluates the way you expect it (even if that means you might have to
modify your version string of the updated package slightly). And testing a
package for the expected result is required anyway.
If anybody has a suggestion how to handle all possible versions correctly
please let me know. Up to now I am still quite satisfied with the results the
current algorithm achieves.
If you never heard about "I"/"Integration" releases, then have a look at the
eclipse project. They use integration and milestone releases as well as RC.
I did not add the single-character "b" to the list because I think it's more
common that "b" is used for "build" in some packages and therefore it means
that 1.0b2 is newer than 1.0. As you can see without knowing the versioning
scheme of the concrete project it's (even for a human) impossible to answer the
question whether 1.0 or 1.0b2 is newer.
I've updated the algorithm once again. Now it's slightly optimized - if two
identical strings are passed, then no split and enhanced comparison is done
(speeds up comparison). In addition I added the possibility to append your own
"volatile version strings" to config.xml - so if you have special cases you
might add it there. However it's clear to me that the way it works and the
effect these parameters have are very difficult to explain - so I suggest to
leave it at default.
Changes:
MOD: Updated the list of volatile release markers (see previous change).
NEW: Added the possibility to define "volatileReleaseMarker" parameters within
config.xml. This allows users to extend the list of volatile release
markers on-the-fly.
I am still open to feedback - either positive or negative.
Currently my impression is that the change is mainly positive and should be
kept.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
