2009/9/18 Jörg Schaible <[email protected]>: > Stephen Connolly wrote at Donnerstag, 17. September 2009 23:21: > >> these are signatures of the entire javase classpath > > Cool. > > [snip] > >>> [snip] >>> >>>> Option 3: >>>> >>>> bgid:java1:1.0.1, bgid:java1:2.2.1, bgid:java1:3.2.20, >>>> bgid:java1:4.2.19, >>>> bgid:java1:5.0.19, bgid:java1:6.0.15 >>>> >>>> pros: >>>> * we have the build number to fix bad signatures >>>> * for 5.0+ the version number matches the marketeers version number >>>> for >>>> java * we still have classifiers for vendor specific signatures >>>> anti: >>>> * not the version numbers that people are expecting >>> >>> +1, and I thing you meant "java" as artifactId in all this >>> cases ... ;-) >> >> nope I meant java1 ie encode the first digit of the version in the >> artifactid > > OK, I missed this. Looked like '1' was the first number of the version. Then > I'm voting with Brett for option 2 although I don't see the need to > separate the 3rd version element with something else then a plain dot. >
You should check out how maven evaluates version numbers, esp Maven 2.x if the version number does not match the form \d+(\.\d+(\.\d+)?)?(-\d+)? then version ranges will not work. Brett's suggestion is to revert to toString comparison for the whole version, as such you get something like this 1.4.2_18 < 1.0.0 < 1.4.2-1 because 1.4.2_18 does not match the maven version rule => major version = null, minor version = null, incremental version = null, build = null and qualifier = 1.4.2_18 while 1.0.0 matches the rules => major version = 1, minor version = 0, incremental version = 0, build = null. and IIRC major version == null < major version == 1 and so to get version ranges to work you have to specify the bounds as toString versions, e.g. [1.4.2_01,1.4.2_20) everything is fine until either sun/oracle/ibm/harmony/etc rushes out another 80 builds of 1.4.2 which is EOL, so not lightly... but 1.6 is not near EOL yet and they're at least up to build 16 there... or until sun/oracle releases java 1.10... that was my thinking on dropping the first digit of the version number... and besides, if there is a java 2.0 (as opposed to the java 1.x series) i suspect it could be quite a jump [remember the markateers have not had much luck changing the 'developer' version number of java] on top of that, the version number would "match" the markateers version number for 5.0+ so that in reality we are only retrospectively rebranding java 1.1, 1.2, 1.3 and 1.4 in fact, given that 1.1, 1.2 and 1.3 are rather rare, we could just ignore specific builds and call them 1.1, 1.2, 1.3 and be done with them... so that leaves the question of what to do with 1.4... given that there were problesm with the 1.4.0 and the 1.4.1 branches, I hestiate to throw away digits.... we could always say "feck the lot of yea" and use the build number for our own purposes... another solution is to cheat and add 100 (or even 1000) to the build number so that 1.4.2-19 is our first go at java 1.4.2_19, if we find a mistake then we release 1.4.2-1019, another mistake => 1.4.2-2019, etc and then if we find mistakes presumably we have to re-publish 1.4.2-20 as 1.4.2-1020 and 1.4.2-2020, etc that could be one strategy to use... after all, we're not planning on making mistakes generating these signatures ;-) all we need to decide is how to correct them if we do! > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
