This must be simple yet I'm just not seeing it.
(we often, unfortunately, have a number of different versions of our software on the go - both major and minor revisions).
What I want to do is basically have a line in a topic that says:
1. Uninstall Software [insert version x.x]
...and then compile the documentation depending on the selected version.
Note: We have users where we need to keep things simple and specific. Plus, I'd like to use the above concept elsewhere in our documentation.
The two options I thought of were:
1. Put the same step in for each version and condition the text. This seems to me long-winded as if we have 6 different versions, I would have 6 different lines that say the same thing.
2. Use a variable set and then just update the version number each time I do a specific compile (so if I have a variable that says currentVersion = 4.5 and previousVersion = 4.4, I would just change those numbers depending on what I'm compiling).
Are these the only two options or am I missing something obvious? (aside from manually doing it, which is not really a good option - although it's the current one I'm using but I want to streamline this process).
Thanks,
Controlling Version Numbers in Documentation
-
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Controlling Version Numbers in Documentation
I understand what you're after, but I think you may be trying to do too much. The biggest thing to me is, how do you know which version the customer has now? (from the first line of your steps). Can you guarantee that all of the customers had the same previous version? Probably not: some people would not have upgraded to 4.4 and still be on 4.2, or 4.0, or 3.x even (in my experience, no matter how good the new version is there's always someone who doesn't upgrade, even if upgrading would help them - people are weird sometimes). I think it would be best to say "Uninstall your existing version of SuperFantabulousSoftware" and not worry about which version the user currently has installed.
A variable would work for the current version, provided you don't have to support multiple versions in the same output file. If you do have to support multiple versions in one output, a single variable wouldn't work. You could have multiple variables, but that doesn't sound much simpler than using conditions.
A variable would work for the current version, provided you don't have to support multiple versions in the same output file. If you do have to support multiple versions in one output, a single variable wouldn't work. You could have multiple variables, but that doesn't sound much simpler than using conditions.
Until next time....
Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare
-
- Sr. Propeller Head
- Posts: 185
- Joined: Sat Mar 04, 2006 3:05 am
- Location: Melbourne, Australia
- Contact:
Re: Controlling Version Numbers in Documentation
Hey Kevin, thanks for that.
We run agile development where we do currently support different versions of our software (as an example, everybody gets v4.0 but only the agile clients (the ones who pay the big bills) get v4.5). You're completely right about not knowing what versions some of our clients are on. The usual small business problems. Docs currently say "uninstall existing version," but I wanted to see if there was a way of actually saying which version.
We're trying to get out of the habit of supporting different versions but as a smallish company (13 people a mixture of support and devs), it's difficult to take a financial hit to move to .net dev (that we pay for) whilst our devs are still coding vb6 (which clients keep paying for).
Cheers,
We run agile development where we do currently support different versions of our software (as an example, everybody gets v4.0 but only the agile clients (the ones who pay the big bills) get v4.5). You're completely right about not knowing what versions some of our clients are on. The usual small business problems. Docs currently say "uninstall existing version," but I wanted to see if there was a way of actually saying which version.
We're trying to get out of the habit of supporting different versions but as a smallish company (13 people a mixture of support and devs), it's difficult to take a financial hit to move to .net dev (that we pay for) whilst our devs are still coding vb6 (which clients keep paying for).
Cheers,
-
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Controlling Version Numbers in Documentation
That change over (VB6 to .NET) is exactly what we're doing as well. We do have the advantage that our software is hosted rather than installed on user's local systems, so updating everyone isn't hard for us (we own the servers so we upgrade when we feel the new version is in the best interests of the client).Robotman wrote:Hey Kevin, thanks for that.
We run agile development where we do currently support different versions of our software (as an example, everybody gets v4.0 but only the agile clients (the ones who pay the big bills) get v4.5). You're completely right about not knowing what versions some of our clients are on. The usual small business problems. Docs currently say "uninstall existing version," but I wanted to see if there was a way of actually saying which version.
We're trying to get out of the habit of supporting different versions but as a smallish company (13 people a mixture of support and devs), it's difficult to take a financial hit to move to .net dev (that we pay for) whilst our devs are still coding vb6 (which clients keep paying for).
Cheers,
I hear ya on the supporting multiple versions, it is a huge pain. The only way around it that I know is to hold the line and only give the good customers a version when it's ready for the whole world. But that is a difficult change over for management in small companies to get comfortable with, so I understand completely that it's easier to say it than to do it.
Until next time....
Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare