We have one product of version 1.14.0019059. But it is not able to upgrade on 1.13.0219038. It throws error "New version is already present. Please uninstall previous version."
I am not able to understand why Installshield is not able to upgrade the product even if there is a minor version upgrade.
We are using Installshield 2018.
https://learn.microsoft.com/en-us/windows/desktop/Msi/productversion states:
The value of the ProductVersion property is the version of the product in > string format. This property is REQUIRED.
The format of the string is as follows:
major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
Related
I am following along the examples in the vulkano-rs website and at the section where it says to create an AutoCommandBufferBuilder, it says to use AutoCommandBufferBuilder::new() to create it.
However, in the latest version of vulkano-rs - 0.23.0 - this method is missing.
If I downgrade to version 0.22.0, the method exists.
So, how do I create an AutoCommandBuffer in the latest version of vulkano-rs?
From vulkano-rs/vulkano#1527:
AutoCommandBufferBuilder::new renamed to AutoCommandBufferBuilder::primary/secondary. For primary form there is a new additional 3rd parameter. Use CommandBufferUsage::MultipleSubmit for this parameter to fulfill the same behavior you previously had with old new constructor.
Is There any Options to Clone a Word / Excel / Presentation Based on document version number
for Ex:
version - 4
version - 3
version - 2
version - 1
Here I need to clone Version 4 In Onlyoffice Document Integration Server
and without any mismatch of editor contents
here I uploaded the image in that 7 version are there, I need to clone a 4'th version (which means version 4,3,2,1 and I don't want 5,6,7) it's not like rollback, original document should not get change while cloning.
Please describe the case more detailed, we need more information about the whole process, i.e. are you going to just copy the file or start a new conversion process?
Could you please specify if the versioning already works in your environment.
If yes, how is it organized.
Im trying to automate deployment of perforce (p4 & p4v) using puppet. For this I have created a perforce resource
perforce { 'p4' :
version => '>= 15.1',
ensure => 'present',
}
The problem I have is how to determine installed version. Perforce sort all tar balls in release order .../R15.1/... but running p4 -V yields a version number that looks more like date and build no , e.g. 2016.2.345671
Is there a way that I can get the release installed?
I'm not really sure what you're asking since it sounds like you already know about p4 -V, but will try to answer the implied question of "what do all the pieces of the version string mean"...
"2016.2" is the same as "r16.2" -- releases are named according to the year of release, and there have historically been two major releases most years so the version numbers tend to be of the form YEAR.1 and YEAR.2.
The number at the end of the version string in the binary is basically the patch level (it correlates with changes in the release notes).
Here's an example of using a regex to deconstruct a Perforce version string:
https://swarm.workshop.perforce.com/files/guest/sam_stafford/scripts/itest.pl#401
I am using GitVersion (version 3.5.3 if it matters), and getting some unexpected results; specifically the produced version has an unexpected commit count portion. Looking at the log I can see the commit count is calculated correctly, but the base version used by GitVersion is wrong (or at least not what I thought it would be).
However the log file for GitVersion is less than helpful, it just lists a series of tags, then a long list of merge bases, and at the end it just says which base version it decided to use.
Can GitVersion let me know somehow why it chose that specific base version?
I am not sure, you already checked or not; but it is explained how they calculate base version and also new versions in their documentation
UPDATE: Added main information from documentation.
Architecture
GitVersion has three distict steps for calculating versions in v3.0.
If the current commit is tagged, the tag is used and build metadata (Excluding commit count) is added. The other two steps will not execute
A set of strategies are evaluated to decide on the base version and
some metadata about that version. These strategies include
HighestReachableTag, NextVersionInConfig, MergedBranchWithVersion,
VersionInBranchName etc
The highest base version is selected, using that base version the new
version is calculated.
Visually it looks something like this:
Base Version Strategies
HighestTagBaseVersionStrategy - Finds the highest reachable tag from
the current branch
VersionInBranchBaseVersionStrategy - Extracts version information
from the branch name. eg release/3.0.0 will find 3.0.0
ConfigNextVersionBaseVersionStrategy - Returns the version from the
GitVersion.yaml file
MergeMessageBaseVersionStrategy - Finds version numbers from merge
messages. eg.
Merge 'release/3.0.0' into 'master' will return 3.0.0
FallbackBaseVersionStrategy - Always returns 0.1.0 for new
repositories
Each strategy needs to return an instance of BaseVersion which has the following properties
Source - Description of the source. eg `Merge message 'Merge
'release/3.0.0' into 'master''
ShouldIncrement - Some strategies should have the version
incremented, others do not. eg ConfigNextVersionBaseVersionStrategy
returns false, HighestTagBaseVersionStrategy returns true
SemanticVersion - SemVer of the base version strategy
BaseVersionSource - Sha of the source. Commits will be counted from
this Sha. Can be null (eg ConfigNextVersionBaseVersionStrategy
returns null)
BranchNameOverride - When useBranchName or {BranchName} is used in
the tag configuration, this allows the branch name to be changed by a
base version. VersionInBranchBaseVersionStrategy uses this to strip
out anything before the first - or /. So foo ends up being evaluated
as foo. If in doubt, just use null
I have some code which I am attempting to use to "rollback" a sharepoint document and it's metadata properties to a previous version using ootb version control and the SharePoint API. Here is a sample of my code:
int versionCount = item.Versions.Count;
if (versionCount > 0)
{
// this only restores properties
item.Versions.Restore(1);
}
The expected result of calling restore using 1 (the newest version before the current version) would be to restore the file and metadata. Instead, only the metadata is restored and the current file is copied to the new "restored" version.
The versions page clearly displays multiple versions and restoring through the UI restores the desired file.
Furthermore, I have attempted to use item.File.Versions only to find item.File.Versions.Count is 1.
Can anyone provide any insight?
The versions page generates a version entry for each relevant combination of file and item versions. When SPFile.Versions is 1, this indicates that the file has one version in addition to the current version. SPListItem.Versions contains all versions of the file, including the current version (at index 0).
When SPFile.Versions.Restore(iIndex) is called, the file is restored along with the associated SPListItem version which applies to this file
Your 'SPListItem' would have a File property, type SPFile. This also has a .Versions property.. you might have to use that or both.