| RE: [higgins-dev] versioning higgins libraries |
|
I guess if we could cause this build to fire off at will, then we could make time-critical changes, build the library and then have others pull the latest changes.
In the past, the date wasn't reliable because it didn't say anything about the source of the build. We have, in the past built IdAS locally, and then redistributed that with the LDAP CP. Because we built locally, there's nothing which guaranties which updates were on that local machine.
This still might be a small issue with using dates. A build on a given date may or may not include all the fixes committed on that date. We get around this in Bandit builds by using the latest SVN version as the build number -- that way we know exactly what has been committed in that jar.
>>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 12/15/06 12:39 PM >>> We are already recording most of this information on the download pages and various associated objects (0.6.0 N20061215 was last night's IdAS build.) and could use it to more fully label the .jar. In what way do you mean the build date is not reliable? Do you mean because it is not part of the .jar name? Would labeling the jar .0.6.0.N20061215 meet your needs? -----Original Message----- Paul, A recurring issue that pops up is that of versioning idas.jar. As it is, people only have the date to rely on, but that's not reliable. I assume we'd want a number that includes a major version, minor version, and build number. It'd good to have the build number auto increment. I stubbed out the beginnings of an attempt at this in the idas build.xml, but haven't gotten any further. Maybe the best thing to do is to get someone to own this task. Jim |