On 04/08/16 00:08, Warren Young wrote: >> This means that the same >> information is available in two different places > > Only two? Aren’t you the lucky one. :)
Not that lucky, unfortunately. :( That was mostly referring to cases such as sqlite and even fossil itself. In our case it refers to how some of the more recent repositories have been set up. There are old monolithic repositories which acted as "catch-all" repositories back in the day and which we have been unable to break up for various reasons. They have many different components and versions in the same repositories. Then again, some of them are stuck in CVS and Subversion, but my hope is to someday split them up as much as can possible be done and convert them to fossil repositories.. > 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? Yeah, so you just perfectly summarized why versioning is a massive pain in the you-know-what, and that tools even today are lacking in helping manage version numbers. And it gets really fun when people try to be clever and have "funny" schemes like "the version converges towards pi.". (Which I myself thought was funny and clever until I started writing tools for managing version numbers..). I can't answer your question without dedicating some time to it, and I can't say that I would come up with an good manifest.tags-solution for your specific case. That's one of the things I realized after a few failures -- whatever scheme you come up with, it has its limitations. There's much I can relate to in the procedures you described, so I definitely understand where you're coming from. > 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. No worries, I didn't take it as a dismissal; but you're highlighting something I should have been clearer about: I was primarily aiming to solve one particular problem for one, as I see it, fairly typical case. Looking at the open source projects I follow closely, such a scheme could be used for the majority of them. That said, there are plenty of cases where its use would be very limited. >> Someone(tm) needs to make sure they match. > > Or, as we have both discovered, some *thing*. This is a task for automata, > not humans. Exactly. >> Each new released version is tagged using a <projectname>-<version> >> tag. > > Tagged how? Manually? Yes, but we have some tools to assist in that as well. I have a script which automatically tags "next version" (for fossil projects): $ revup major mytest-1.0.1 -> mytest-2.0.0 $ revup minor mytest-1.0.1 -> mytest-1.1.0 $ revup mytest-1.0.1 -> mytest-1.0.2 ... but it has been kind of flaky, so it's rarely in use in its current state. (Also, strictly speaking, it breaks the documented process of version assignment..). Somewhere someone will ultimately have to perform some manual action. I don't want to go into too many specifics, but in some of our cases, there are documents which are called "How to build X", and developers are meant to follow the instructions and never skip a single step, and do each verification, and check a box in a protocol for every step performed. Once finished the protocol is signed and archived. What we found though was that everyone gets it 100% correct the first few times, but after a while people tend to get into the "This part is easy, I know this by heart"-mindset, and they check the "I did stage x, y, z" boxes without actually doing all the verifications. So there are different ways to tackle such problems. Management say it's done by adjusting processes and procedures. I'm tend to take a "develop better tools" approach. Also, I'm lazy, if I have to do something more than once, I generally try to script it. :) People may think I'm being oddly picky about version numbers, but there's context to it. Some of these systems are developed under contracts which state that "if there's a flaw in the traceability chain, we can demand money back". Mismatching version numbers is a very clear indicator that such flaws exist. Every little bit of +1 automata, -1 human interaction in mundane tasks helps lessen the risk of such mistakes. >> 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. Hmm.. $ fossil status repository: /Volumes/ramdisk/mytest/../mytest.fossil local-root: /Volumes/ramdisk/mytest/ config-db: /Users/jan/.fossil checkout: 504d0bfcda9be2e7b365be2331468b1363a3f719 2016-08-03 14:21:07 UTC parent: 569e2a7bb99c919dad0bbb9d6158a2b31aaf4850 2016-08-03 14:17:57 UTC tags: trunk, mytest-0.0.1 comment: Added test.c (user: jan) $ grep ^T manifest $ grep mytest manifest $ cat manifest.tags branch=trunk trunk mytest-0.0.1 Is there supposed to be a T-entry in the manifest file? *confused* >> 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. We have exactly those kinds of repositories you bring up as an example (RPC client/server applications, with stubs built from IDL's). In those cases, the version extracted from the tag is used as an overall project version number; in practice used in the installation package (both as in "Welcome to X 2.9.1 installation", as well as X_2_9_1_install.exe, X-2.9.1.tgz|rpm). Version numbers in about-boxes and the like which identify specific version of client and server builds are solved mostly using manually hardcoded version numbers in header files and are supposed to be set and verified using those protocols I mentioned earlier -- highly manual, and unfortunately not explicitly solved using manifest.tags. So the simple answer is that manifest.tags, for us currently, only solves the issue on a "repository level", which is sufficient for the majority of repositories since they are one uniquely versioned component per repository. Though I should point out that the scheme I used as an example is merely the convention we happen to be using. It's completely free-form, so it's perfectly feasible to use a generic name like "project-<version>", or "release-<version>" and use multiple tags: $ fossil tag add release-1.2.4 `cat manifest.uuid` $ fossil tag add server-1.0.1 `cat manifest.uuid` $ fossil tag add client-1.1.3 `cat manifest.uuid` The build script would obviously need to make sure it can extract all of them for the appropriate sub-components. This is a pretty messy scheme imho, and it has some annoying drawbacks, but it illustrates one way to let the SCM system keep track of version numbers for sub-components as well. > Does your build system use this project name to detect which binary > package(s) to build? Sorry, I don't understand the question; interpreting from context I'm going to take a stab at answering. I apologize if I completely misunderstood (it's well past bed-time here..). The build server gets a request to build a specific version. It creates a new clean checkout directory, checks out the specific version (using the tag), and builds the entire component and sub-components (i.e. all binary targets within the repository). Any external dependencies are handled on a higher level (the components rely on that their dependencies have been set up before the build process starts). Finally the build script packages the build targets into one or more platform-specific package file(s) which includes the tagged version in their file names. We aren't allowed to rebuild release versions of some of the components, so once a release version has been successfully built and packaged, the build system refuses to build it again. (This is to guarantee that there will "never" exist more than one version of released versions). To simplify matters, we use that same limit for all our own components -- so in our case it's never really a matter of building different sets of binaries in a repository for tagged release builds. In practice we have plenty of different build systems and several source management system. The paragraphs immediately above refers to the ones which are either using the manifest.tags feature or which are prime candidates for being made into such. Those really long and annoying "manual steps" documents aren't going away anytime soon, unfortunately. Though I'm doing my best to make sure they do. My pan-ultimate goal: $ ./build_all.sh --make-ding-sound-when-done -- Kind Regards, Jan _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
