On Aug 3, 2016, at 10:24 AM, Jan Danielsson <jan.m.daniels...@gmail.com> wrote: > > This means that the same > information is available in two different places
Only two? Aren’t you the lucky one. :) In my current main projects, the release version number appears in: - the top-level build system file (configure.ac, CMakeLists.txt, etc.) - the most recent section at the top of the ChangeLog - the source file feeding “./myprogram -v” or the About screen - the binary package description file(s) (e.g. *.spec for RPM) - the Fossil release tag - the comment on the Fossil checkin creating the release tag We drive everything from the first item on that list, except that the ChangeLog remains manually-updated. In that sense, we have “only” two places to change the version number, too. The formal release version number in our system has two parts: the human-facing version number (e.g. 1.2.3) and the binary package release number (e.g. -1) which combine to give the formal release number, 1.2.3-1. These two parts may be in the same top-level file (e.g. CMakeLists.txt for a CMake based project) or in separate files (e.g. configure.ac and *.spec.in for an Autoconf + RPM based project). We use the binary package release number to distinguish two different Fossil checkins both tagged someproject-1.2.3. The checkin comment for the first tag will say “Release someproject v1.2.3-1”, and the second “…-2”. The Fossil tag checkin and its checkin comment are generated by a mkrel script we wrote which parses the version number out of one of the generated files, such as *.spec file in an Autoconf + RPM based project, which as I have said is generated from *.spec.in and configure.ac. Other files come off of this, such as a version.h file for a C++ project, generated from version.h.in by Autoconf, which gets it from configure.ac. Because we want the binary package release number in the Fossil release tag’s checkin comment, generated by the mkrel script, Fossil doesn’t get involved until nearly the end of this process. My initial thought from that observation is that this means we can’t really replace our current scheme with your scheme. If you had to redesign our scheme to use your new feature, how would you go about it? I don’t mean to dismiss your efforts, Jan. It solves a real problem, and I wish it was available before we started solving these problems on our own, many years ago. I’m willing to offer a weak sort of endorsement for trunkifying it, since I haven’t played with it, but I can see that it’s useful already. > Someone(tm) needs to make sure they match. Or, as we have both discovered, some *thing*. This is a task for automata, not humans. > Each new released version is tagged using a <projectname>-<version> > tag. Tagged how? Manually? > The build system iterates through each line of manifest.tags I don’t see what your build system is getting from manifest.tags that it couldn’t already get from the T card in the current manifest file. > Thoughts? Your vague use of <projectname> makes me wonder if you’re using this in any Fossil repositories that host multiple related projects that nevertheless build to separate outputs, such as the client and server for a distributed system, giving two separate binary packages, each possibly with different version numbering. Does your build system use this project name to detect which binary package(s) to build? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
