Hi guys,
Allen Bierbaum wrote:
>
> I don't think there is an API to get this information yet, but I agree
> that would make it much more useful. Is there already an API to get the
> version number of a library?
No, as it is not stored in the library. All the library does is submit a
string that is printed on osgInit.
I wanted to avoid a complicated interface, since you don't know which
and how many libs are used. There's no problem giving access to the
strings, but do you think you need more controlled access? Strings are
nice for printing but not much else. :)
> If so we should probably put the retrieval
> of the revision number right next to the API version interface. Some
> projects even consider the revision number part of the API version
> number, for examples: OpenSG "1.9.4 r345". I know OpenSG doesn't use
> numeric version numbers so this may not make sense for us though.
I'm not sure i get this part.
> One comment on the revision number code. As far as I can tell, the
> revision number does not tell us what code was used to compile the
> library. It just says what revision was checked out. This may sound
> like the same thing, but think about branches (both release and
> development) and tags. Because the revision number is shared over the
> entire repository, there is no way based only on revision number to know
> if we are building from a branch, tag, or the trunk.
Hm, good point.
> It looks to me like there are two ways to solve this:
>
> 1. Combine the version number of the library (2.0.x) with the revision
> number from the code. This almost gives us a fully unique value and
> will work in all standard releases cases (branches for releases and trunk)
>
> 2. Make the path from the repository part of the versioning information
> with the revision number. This would would for releases, but would also
> work for development branches and tags.
>
> There are probably other options I am missing. Any other ideas?
1. only works when we actually change the version number very
meticulously. I'd opt for 2.
Marcus Lindblom wrote:
> The repository path should definitely be available. It's very useful to
> disambiguate releases etc.
>
> As I showed earlier, we use all available info (version number, revision
> number, path, modified flag) in our releases.
Modified is a bit of a problem, as it doesn't really help on a
lib-by-lib basis (and not really at all, IMHO). I print a warning when
it finds a modified file, I'd consider that a bug. But the path is needed.
Dirk
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
