Clarification: Versions have 4 segments a.b.c.d The first three (a b c) are *numbers* not random strings and they are compared numerically. The fourth segment is the qualifier and is an uninterpreted string from a limited alphabet. You are fine to do whatever you like with that segment.
Note, we do the number shifting idea in the third segment for maintenance streams in the Eclipse project. See the http://wiki.eclipse.org/index.php/Version_Numbering#When_to_change_the_servi ce_segment Jeff From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baptiste MATHUS Sent: Monday, April 07, 2008 9:51 AM To: Equinox development mailing list Subject: Re: [equinox-dev] Customize versioning scheme 2008/4/7, Alex Blewitt <[EMAIL PROTECTED]>: On Apr 7, 2008, at 13:48, Baptiste MATHUS wrote: Hi all, We're using Eclipse RCP as the platform for our UI. We're almost done with dev and are beginning to look at the packaging/deployment phases. OSGi specifies the org.osgi.framework.Version class to manage versioning by default with x.y.z.qualifier scheme. Our scheme is not very far from it, but not the same, it's something like a.b.c.d.e.qualifier (two numbers more). So my question is simple: is this possible to inject a custom versioning scheme (for example, we could inherit/extend the current Version class to manage our case) ? For bundles, no, the OSGi versioning is fixed. I'm not sure of the point of having so many numbers, but if you have a.b which are on the whole the same throughout other releases, you might like to call your bundle foo-a-b_c.d.e.qualifier instead. You'd lose the connection with the version comparisons but since you'd end up with different named bundles each time, you could easily do that approach. Well, easily, I'm not sure it would be the easiest way :). We'd have to maintain some mapping between the versioning scheme used in our company (the one I mentioned) and the one supported by OSGi. The other thing would be to use some kind of bitshift to represent the numbers e.g. a.b.(c*1024+d*512+e*128).equalifier. Well, this idea workaround suits me better. I guess this would even be preferable to use a decimal shifting approach, to stay human readable. We could decide that there would always be less than 100 for c, less than 100 for d and say less than 1000 versions for e. This way, 1.2.3.4.5.alpha-1 would become 1.2.0304005.alpha-1. Maybe a extendable Versioning Service could be an idea for OSGi 5 ? :-). Because I guess our case isn't the most complicated versioning scheme to be found in the software area. Anyway, thanks for the quick answer. Cheers -- Baptiste <Batmat> MATHUS BMathus at Batmat point net - http://batmat.net Si chacun de nous a une idée et que nous les partageons, nous repartirons tous les deux avec deux idées... C'est ça le Libre.
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
