Thanks for the heads up Sean! I don't expect any build problems since we don't depend on generate-vers.pl anymore, though the buildbots will let us know for sure :)
On Linux, we already switched away from the Apple versioning scheme. Instead, we just use whatever version clang reports, and include the SVN/Git revisions of LLDB/Clang/LLVM used to build. Our motivation was to keep "lldb -v" consistent with the version number from the Debian package, which is tied to the major llvm/clang releases. Dan On 2013-03-07 5:21 PM, "Sean Callanan" <[email protected]> wrote: >I am currently revising the versioning scheme for LLDB. At Apple, we >currently are using version 1xx for versions from a branch meant for use >with Mac OS X and 2xx for versions meant for use with iOS. Our 1xx >version numbers are about to collide with 2xx, so we are changing the >Apple version scheme as follows: > >lldb-300.1.10 > >300 indicates the major version. This changes only rarely (we anticipate >at most a few times a year). >.1 indicates the branch number. As noted above, we have different >branches of LLDB for use in different scenarios. >.10 indicates the merge ID roughly, we increment it when we merge to >our release branches from trunk. > >The API headers have macros reflecting the major version and the merge >ID, as well as a macro containing the entire version as a string. > >I have modified scripts/generate-vers.pl to generate proper versioning >information. I have also modified lldb_private::GetVersion() to use the >output from that information. > >Please let me know if you encounter build trouble with these changes. > >Sean >_______________________________________________ >lldb-dev mailing list >[email protected] >http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
