Package versioning
Hi All,
How do you guys do your package versioning? I understand the major.minor.build way of doing things but it’s very restrictive. With the first 2 decimal points having a max value of 255… and Windows Installer ignoring anything after the 3rd point…
For example, what if I have 2 Java versions; 1.5.0.60 and 1.5.0.80 and I want to represent an in-house release number. I can’t have 1.506.2 (where 2 is the release number) as 506 is greater that the 255 max value and I can’t have 1.5.2 as this is ambiguous.
Also, if you’re transforming a vendor MSI is it ok to change the version number?
Any thought?
Cheers
How do you guys do your package versioning? I understand the major.minor.build way of doing things but it’s very restrictive. With the first 2 decimal points having a max value of 255… and Windows Installer ignoring anything after the 3rd point…
For example, what if I have 2 Java versions; 1.5.0.60 and 1.5.0.80 and I want to represent an in-house release number. I can’t have 1.506.2 (where 2 is the release number) as 506 is greater that the 255 max value and I can’t have 1.5.2 as this is ambiguous.
Also, if you’re transforming a vendor MSI is it ok to change the version number?
Any thought?
Cheers
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
kkaminsk
17 years ago
Best effort in most shops I go to. If you can't get the real version number into the MSI version field then we just fake it. Most of the time Windows Installer patches or native MSI upgrades are not being performed at the sites I go to so it usually isn't a big deal. I am not necessarily saying this is best practice but this is what I see in the wild.
edited for better clarity
edited for better clarity
Posted by:
mazessj
17 years ago
For something like JRE, it's probably not a good idea to modify the vendor's version numbers. This might interfere with upgrade support. Consider putting your package version information somewhere else, such as the Summary table, which can be accessed when you bring up Properties of the file. If you need to be able to use the internal version number in the package, then consider storing it in a company standardized property. Either way, you can establish any versioning standard that you want.
I've also seen some companies put a standardized version number into the file name itself (e.g. AppName_01500060.mst). It requires careful definition to determine what the version number really is.
--Josh
I've also seen some companies put a standardized version number into the file name itself (e.g. AppName_01500060.mst). It requires careful definition to determine what the version number really is.
--Josh
Posted by:
AB
17 years ago
We use version numbers within the MSI and Release candidate numbers in the MSI file name...
I fondly recall the arguments I've had in the past relating to setting standards regarding version info - some have been a little too heated :)
So with vendor MSI's we (well, I...) keep the existing number where possible and our mst will contain the Release number (e.g. R1.0.0)
With snapshot MSI's some think the MSI version number should be the same as the Release number - others believe it should be the application version
Pistols at dawn seems a tad extreme but it's surprising how passionate some people get about a bunch of numbers...
Have a lovely day.
Regards,
Al
I fondly recall the arguments I've had in the past relating to setting standards regarding version info - some have been a little too heated :)
So with vendor MSI's we (well, I...) keep the existing number where possible and our mst will contain the Release number (e.g. R1.0.0)
With snapshot MSI's some think the MSI version number should be the same as the Release number - others believe it should be the application version
Pistols at dawn seems a tad extreme but it's surprising how passionate some people get about a bunch of numbers...
Have a lovely day.
Regards,
Al
Posted by:
fuz_kitten
17 years ago
Tell me about it! I’m in the mist of this argument atm. Oh well, I guess we just have to settle on a method and stick with it. Having the release in the version property makes ‘upgrades’ so easy when something gets push out that’s not quite right (which happens all to often :)
Thanks to all that replied. May the versioning war continue.
Charlie
Thanks to all that replied. May the versioning war continue.
Charlie
Posted by:
nheim
17 years ago
Hi Charlie,
we try to handle it very pragmatic, especially with vendor MSI's.
JRE is very good example: Until version 1.5.0.70 they not even had the right format in the ProductVersion property. But because Sun puts a new Upgrade Code into each new release, the version number isn't that important.
Regards, Nick
we try to handle it very pragmatic, especially with vendor MSI's.
JRE is very good example: Until version 1.5.0.70 they not even had the right format in the ProductVersion property. But because Sun puts a new Upgrade Code into each new release, the version number isn't that important.
Regards, Nick
Posted by:
fuz_kitten
17 years ago
Arrr! I’ve just stood up in front of everyone and said that upgrade codes must be kept the same for each release of a software family!
Right, all I have to do it pretend that I know what I’m talking about, and then they will respect my authota!
Cheers!
Charlie v1.4.5 SP2 RC1
Right, all I have to do it pretend that I know what I’m talking about, and then they will respect my authota!
Cheers!
Charlie v1.4.5 SP2 RC1
Posted by:
nheim
17 years ago
Hi Charlie,
very nice version info b.t.w. :-)
Don't justice yourself too hard!
You are right with your statement about the upgrade codes.
The line about JRE was only meant as an example of not so well behavior. In such cases, we just have to live with it, i'm afraid.
Heads up. :-)
Regards, Nick
very nice version info b.t.w. :-)
Don't justice yourself too hard!
You are right with your statement about the upgrade codes.
The line about JRE was only meant as an example of not so well behavior. In such cases, we just have to live with it, i'm afraid.
Heads up. :-)
Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.