From e2bf6bdb764e59a17b7d5f65a1a952d517668c2d Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Tue, 13 Sep 2016 16:48:02 +0200 Subject: Add idea: module to help with managing project versions --- build2/version-management-module | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 build2/version-management-module diff --git a/build2/version-management-module b/build2/version-management-module new file mode 100644 index 0000000..f4086dd --- /dev/null +++ b/build2/version-management-module @@ -0,0 +1,22 @@ +- module to help with managing project versions [idea] + +The place where we have all the information (this project version, all its +dependencies and their versions) is the manifest. So what if we have a module +which loads the manifest (using libbpkg), extracts all this information, and +presents it to the buildfile in a nicely parsed and converted way. That is, +split MAJOR/MINOR/PATCH, pre-release, converted to numeric form, etc. + +We can then use this to set all the buildfile-level values (version, revision, +abi_*, etc) as well as generate the version file and even generate the version +header which will define this library version as well as check versions of +dependencies. This generation will probably be done via a custom/inline rule. + +* Since this module will depend on libbpkg, would make sense to make it dyn + loadable and optional (include pre-generated files in dist). + +* Will require the use of semantic versioning. + +* What about using build2@X.Y.Z? Theoretically, the version module could + even issue this. Though it is optional. + +* Don't think we allow bootable optional modules at the moment. -- cgit v1.1