Hello, Coming from subversion where there is a revision number, incremented by one by each commit, which is very easy to capture in automated builds to be injected as part of the version number of binaries built...
Revision 8745 -> version x.y.z.8745 Revision 8789 -> version x.y.z.8789 The x.y.z is incremented by hand when it means something (release of some tested version). But for the lifetime of a version, there might be some newer builds (small fixes) and they will be auto-tagged with the revision ID as last part of the full version number. In real life this can lead to sequences of file version numbers as: 1.2.3.8745 1.2.3.8749 1.2.4.8801 ... This has many advantages, not the least being to easily spot which among two binaries is more up to date (has simplifications in setup systems). The main limitation is that (on Windows) those 4 parts of a full file version id are each limited to 16 bits. Limiting this model to about 65.000 revisions. After which some offset should be applied (which is easy to do every time the first 3 values are hand changed). Of course this characteristic (a sequential revision ID) is logical in a centrally managed system as subversion and is less trivial in distributed scm like fossil or git. I'm considering replacing the subversion revision ID, for the purpose of defining the file version ID (as above) at release-external build time, by the count of check-ins in the root repository. That is the count returned by 'fossil info' in one of the multiple lines of output (for instance 'check-ins: 8801'). The full version string (as "1.2.4.8801") would then be automatically added as a tag to the most recent check-in on trunk (from which the build is derived). How does that sound to those of you who might have had similar concerns? Been there and rushed away? Or happy to stay? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
