Hello, I have build systems which use the commit id from the manifest to embed the commit artifact id in the binary. I also, in most projects, have an ordinal version number which is loosely coupled between the repository and the build system/source in the sense that I can forget to update the source when I tag a new version in the scm.
Optimally the tagged version _is_ the source version. I had a period when I had a build system run "fossil status" and determined if there were no changes and there was a <componentname>-X.Y.Z tag, then X.Y.Z would be used as a release version number. However, I dislike the idea of the build system requiring the fossil binary to build (in case someone downloads the source in an archived form), so it never got past a quick trial. (In case you're wondering, when the build system didn't detect a "release" version it used a special (reserved) version number scheme which we use for development builds). The manifest solves this issue neatly for the commit id; but can it be made to solve it for version numbers with ordinality? How feasible would it be for fossil to in addition to manifest and manifest.uuid write something like manifest.tags which is simply a file which lists all (current) tags (newline-separated)? Build scripts could grep <componentname>-X.Y.Z to determine the release version. It would also allow build systems to use scm tags to flag certain other attributes; imagine an "experimental" tag, for instance. (For those who haven't used manifests: The neat thing with them is that they are a part of generated source archives). It would also allow tagged version numbers to easily be put into amalgamated sources, for those of us who like to include amalgamation scripts with libraries. Settings-wise, I wouldn't want to add a new option for this, but perhaps the "manifest" setting can grow from a simple boolean to something along the line of a "off, on, full" setting. The idea would be to make the change completely non-intrusive and completely invisible to users who have no need for it. Thoughts? Regarding feasibility; the question isn't whether it *can* be done, the question is whether the queries are too costly to be able to keep the "manifest.tags" updated when required. -- Kind Regards, Jan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
