So I was wondering how to increase the version number or build number with Fastlane tools, so that I don't have to manually change the version.
So the answer to this question where the following two lanes. Keep in mind you need to activate some settings in your project by following this link.
With them I can increase the build number for the current version, or increase the version number and set the build number to 1.
The result will be [ver++] v1.0.0 (1) (you can change the syntax as you please) and it gets automatically committed to git
Build Bump:
lane :buildbump do
version = get_version_number
build = increment_build_number
commit_version_bump(
xcodeproj:"MyProject.xcodeproj",
message: "[ver++] v#{version} (#{build})"
)
end
Version Bump:
lane :versionbump do
version = increment_version_number
build = increment_build_number(build_number: 1)
commit_version_bump(
xcodeproj:"MyProject.xcodeproj",
message: "[ver++] v#{version} (#{build})"
)
end
Related
Is there any way to auto increment the android app version name and version code.
My app version name format-- major.minor.0.build (1.2.0.221)
Version code format -- number of commits (115)
my app manifest file, I have included these two variable
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.mytest"
android:versionName="1.2.0.221" android:versionCode="115">
<uses-permission android:name="android.permission.INTERNET" />
In my azure devops i referred my app manifest file and declared the version code and name like below.
Version Code Format ----- User Defined/Build Id
Version Code (must be integer) ---- $(NUMBER_OF_COMMITS)
Version Code Offset-----1
Version Name --- $(MAJOR).$(MINOR).$(SNAP).$(BUILD)
and I placed by version bumping task above to the android build task. I have defined pipeline variables.
MAJOR ----1
MINOR-----2
NUMBER_OF_COMMITS ---115
SNAP ---- 0
BUILD-----221
And In options tab, I have defined build format like
Build number format ------$(MAJOR).$(MINOR).$(SNAP).$(NUMBER_OF_COMMITS)$(Rev:r)
When i run the pipeline, Through the version bumping taking, the version code was incremented to 116 and published to the APP center with the incremented value.
But, the next time the version code is not incremented from 116 , its again from 115. so, In app center, we can see each release with same version name and version code.
How to auto increment the version code and version name, Where I am doing mistake.
I have declared the following package reference
<PackageReference Include="Abc.Defg" Version="9.9.5.*" />
With the desire that it should pick exactly a version 9.9.5 followed by the highest revision number it can find eg. 9.9.5.1234
Any package that doesn't start with 9.9.5. should be invalid eg. 9.9.6.0 or 9.9.4.0
I am getting the following message when I call nuget CLI command nuget restore but fail to understand how exactly to fix the warning and still get my desired result
WARNING: NU1604: Project dependency Abc.Defg does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results.
FYI, in case it makes a difference, the package version numer isn't declared directly as shown above but instead it is declared in a Directory.Build.props as a Property.
<MyVersion>9.9.5.*</MyVersion>
Which is than used as the following
<PackageReference Include="Abc.Defg" Version="$(MyVersion)" />
Is it possible to fix this with only one version number or do I need to change it to something like this
[9.9.5,9.9.6)
Which, if I am correct, translates to include 9.9.5.0 (0 can be omitted) and everything up to exclusively 9.9.6, so from 9.9.5.0 till 9.9.5.65534 should be valid.
The 9.9.5.* version extends the version range not just up, but down as well.
Lower version numbers that match this wildcard version constraint may not have the required "Abc.Defg" dependency.
The lower version number may need to be set to a version that covers this dependency, perhaps ...
(9.9.5.4, 9.9.5.*)
so if i upload on appstoreconnect and have different bundle version on each target it will be ignored by apple. ignored info when uploading to appstoreconnect
PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}"
PLB=/usr/libexec/PlistBuddy
LAST_BUILD_VERSION=$($PLB -c "Print CFBundleVersion" "$PLIST")
IFS=. components=($LAST_BUILD_VERSION)
major=${components[0]}
minor=${components[1]}
micro=${components[2]}
build=${components[3]}
build_plus=$((build + 1))
old_build="$major.$minor.$micro.$build"
new_build="$major.$minor.$micro.$build_plus"
$PLB -c "Set :CFBundleVersion $MARKETING_VERSION.$build_plus" "$PLIST"
i already made a run-script that change the last number for one target but i dont have idea to change another target using run script
if it 5.5.10.1 then it would change it to 5.5.10.2 for main target. but the other target dont get change
I think you can use User-Defined Setting at the project level, then use that value for all of your targets.
My goal is to deploy NuGet packages (to in-house Nuget server) that auto-increment the version based on date and last Rev, and include a -beta tag.
I am using VSTS to build and package using cake, with a build number format of $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r).
I have a .nuspec manifest file that specifies: $version$, and a NuGet Packager as such:
This works great. But now, I want to have the option of a NuGet packager that produces a package that is tagged as beta, and therefor show in VS NuGet Package Manager as pre-release. I can do this if I hard code the version number with "-beta" appended in the NuGet Packager:
But how can I include the -beta tag AND the the build number? I think I need to include a variable in NuGet Arguments that will return $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r) plus "-beta", but I'm not sure how.
I tried creating a variable (under the Variables tab) with the Build Number Format as the value, then referencing the variable in NuGet Arguments (-Version theVariable), but received as error that the variable is not supported.
I may be going about this all wrong, however my searches have not turned up any hints on how to auto-increment versions from the date, and include a -beta tag.
NuGet Packager with version using build number, adding -beta
I could reproduce your scenario on my side. In my opinion, Nuget pack task with build number doesn't support character or numbers. You may check this task:
case "byBuildNumber":
tl.debug("Getting version number from build number")
if(tl.getVariable("SYSTEM_HOSTTYPE") === "release")
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_AutomaticallyVersionReleases"));
return;
}
let buildNumber: string = tl.getVariable("BUILD_BUILDNUMBER");
tl.debug(`Build number: ${buildNumber}`);
let versionRegex = /\d+\.\d+\.\d+(?:\.\d+)?/;
let versionMatches = buildNumber.match(versionRegex);
if (!versionMatches)
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_NoVersionFoundInBuildNumber"));
return;
}
if (versionMatches.length > 1)
{
tl.warning(tl.loc("Warning_MoreThanOneVersionInBuildNumber"))
}
version = versionMatches[0];
break;
That is the reason why the field $(BuildDefinitionName) and beta could not appear in our package version when we use them in our build number.
If we specify the nuget version in the nuget arguments, but this argument could not parsing predefined variables, like $(Rev:.r).
The limitations of these two situations have caused your current issue.
The workaround to resolve this issue, is using nuget custom task with parameter -version $(Build.BuildNumber) and move the field $(BuildDefinitionName) from our Build number format, otherwise, we still receive the error the version is invalid.
So, you nuget custom looks like:
And the Build number format:
Now, you can see it works fine:
Note:
You said you using VSTS to build and package using cake, but the images you posted shows that you are using NuGet Packagertask in TFS 2015. If you are sure using TFS 2015, I am afraid above workaround will not work for you. Because the custom nuget task is not support for TFS 2015.
Hope this helps.
Just getting started with JOlivers event store library and having issues with some of the Nuget commands in the build.cmd. here's the log, perhaps you're already aware of the issue but i thought i'd put it up here.
=== COMPILING ===
Compiling / Target: v4.0 / Config: Release
S:\SourceControl\Test Projects\EventStore\bin\nuget\NuGet.targets(6,9): error : Input string was not in a correct format. [S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\EventStore.Persistence.RavenPersistence.csproj]
S:\SourceControl\Test Projects\EventStore\bin\nuget\NuGet.targets(6,9): error MSB3073: The command ""S:\SourceControl\Test Projects\EventStore\src\..\bin\nuget\nuget.exe" install "S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\packages.config" -source "" -o "S:\SourceControl\Test Projects\EventStore\src\..\bin"" exited with code 1. [S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\EventStore.Persistence.RavenPersistence.csproj]
The master branch of EventStore appears to be broken at the moment. The 3.0 branch is in better shape but is also slightly broken. To fix the 3.0 branch so that it builds, you need to upgrade the 1.5 version of nuget.exe to 1.6. The easiest way to do that is to execute \bin\nuget\NuGet.exe update -self in the repository. I already submitted a pull request to JOliver with that change.
(I also submitted a pull request with a few minor fixes for the example project.)