Automate Version Numbers on Publish

[beckteck]

Hello,

We use global variables on our opening splash page: <%VERSION_MAJOR%>.<%VERSION_MINOR%>

At the moment we have these set in Config >Title & Copyright to Major 4 and Minor 7. Is there anyway that I can automate a change in the major and minor values on Publish without creators having to go in and manually change the values?

Thanks for any help.

[Tim Frost]

We use FinalBuilder to build a release version of our product and its help. And FB is our central place that always knows what version number it is building, for all components. So naturally we want FB to set the version for H&M too. Before running H&M, an FB build step can automatically write a VARIABLES.TXT file in the H&M project folder containing (but we use different variable names) for example:

VERSION_MAJOR=4
VERSION_MINOR=7

Then when invoking H&M, it passes a command-line parameter, for example "(path to)\FBWEBHELP.INI", a file which contains all our settings for the specific help build, including one which reads: V=(path to)\VARIABLES.TXT

Even if you do not use a build manager like FinalBuilder, this should give you an idea of what is possible, but I am sure Tim Green will pop in here to suggest a neat way of doing similar things within H&M, and where this is all documented! But I sense that you do not want your authors have to modify the project and would prefer those who do the final build to deal with it.

[Tim Green]

Is there anyway that I can automate a change in the major and minor values on Publish without creators having to go in and manually change the values?

Yes, this is built in to Help+Manual. You can do it in two ways: Either with command line publishing, or with the integrated Publishing Task Manager. In both cases you can set it up to produce an unlimited number of different versions and output formats from the same project, with different conditional output and variable settings, different tables of contents and more, all with a single click. You don't need any additional software like Final Builder -- it's all right there in the program.

With command line publishing you just create a text file with the desired definitions of your variables and attach that to the command line. Then you save different versions of the variable definition file for different purposes and save your command line sequences as different batch files that you can call as needed. Using the variable definition file is explained here:

https://www.helpandmanual.com/help/hm_a ... ables.html

See the whole command line chapter for the syntax and full instructions.

The Publishing Task Manager allows you to create publishing tasks for multiple outputs within Help+Manual. Each output "action" within a task includes the output format, TOC to be used, skin or template, variable definitions you want to use and more. You can then publish individual actions or the entire task with all the actions in a single quick process. See this chapter for full details

https://www.helpandmanual.com/help/hm_w ... tasks.html

[michal_novomesky]

How about having a "date" as a version of documentation?
Variables like VERSION_MAJOR, VERSION_MINOR sounds like to me as version for a product/software the documentation is intended for.

[beckteck]

Hi Tim,

Thank you for your response. I have set up the Custom Variables in my Publishing Tasks and assigned them to the inbuilt variables Version_Major and Version_Minor.

How can I define the numbering rules?

E.g I want the minor version to increase by 1 on Publish ?

[Tim Green]

I have set up the Custom Variables in my Publishing Tasks and assigned them to the inbuilt variables Version_Major and Version_Minor.
How can I define the numbering rules?
E.g I want the minor version to increase by 1 on Publish ?

An increment function isn't available in Help+Manual, and it would require a function to write the changed value into the project. You also can't use the numbering variables for this, because they aren't supported in the configuration fields in the Task Manager, and they also don't increment in that way, but only based on the number of times they are used. Also, doing it like that is prone to errors, because would get the wrong numbers as soon as you need to publish more than once for a minor modification or to correct an error.

Tim Frost's solution is really better for this: Publish with the command line interface using batch files instead of the Task Manager and create an external variable definition file for the current values of the variables. Since that is an external, plain-text file, you can have additional scripts set up that will keep the version numbers there at the correct values, or even to update the variables file automatically every time the script is called. But I still wouldn't recommend that because you will get incorrect values as soon as the script is run more than once for testing or error correction or any other reason. You really need to have a more solid system that only updates the version numbers when there has really been a version number increase.

[Tim Frost]

I should perhaps clarify that I only mentioned FinalBuilder earlier because we already used it to control the entire build process for our product. Running H&M from FB is just one task among dozens of others, but the critical thing is that FB is the only place where we increment the version number; we can guarantee that the software and documentation version will always match after a build. If you are willing to control this matching manually, then the batch and text files that Tim Green described make it equally simple to set the documentation version number without needing to open the H&M program to do so. There are other much simpler tools than FB around (including one from the makers of FB) which can automate many Windows tasks, and which could automatically increment documentation version values for you; but this would have the disadvantages he also mentions.