How to increment version number according to last approved iOS version - fastlane

I know that there is increment_version_number lane, but it increments version that is placed in Info.plist file. It means that after every uploading to TestFlight developer have to update Info.plist file with new version.
Also, Fastlane has get_version_number lane but I could not get to make my script work, because it can't increment version like 2.4.1 with the last digit.
So, how I could make +1 (to last digit) to approved version in TestFlight, which is currently 2.4.1 ?

If you have an existing upload in Testflight for an app, you have to increment either the Version number or the Build number (or both).
The Version number can be incremented automatically with increment_version_number (as you noted), but you should specify what to increment.
In your case (v2.4.1): the major version number is 2, the minor is 4, the patch is 1.
So you should add this snippet in the Fastfile before building/archiving the app:
increment_version_number(
bump_type: "patch"
)
However I would not recommend to set version numbers automatically because the app’s version number depends on what you provide in the update. If it’s just a bug fix release or performance optimisation then increment the last digit the patch. If you’ve added some cool new features, you should increment the minor version. If the update was like a rewrite from scratch, a full redesign or some breaking change introduced then I would increment the major number in the version. It’s not elegant to always increment the patch number because the version number has a meaning.
In the project I’m working on we used to bump the version numbers manually upon a release, but increment the Build numbers automatically with Fastlane.
Here is what we did:
1.) Enable Apple Generic Versioning in the project: (Project > Build Settings > Versioning > Versioning System: Apple Generic)
2.) Set base build number: (Project > Build Settings > Versioning > Current Project Version: 1)
3.) Add the following simple Ruby helper class to fastlane/utility folder:
changelog_helpers.rb:
class BuildNumberFactory
class << self
def make
`git rev-list HEAD --count`
end
end
end
4.) Add this line to the very first lines in Fastfile:
Dir.glob('./utility/*').each { |file| require file }
5.) Usage in FastFile:
lane :your_submit_testflight_lane do
increment_build_number build_number: BuildNumberFactory.make
# gym, pilot, other actions after setting the build number
end
This method assumes that you use Git for version control. Basically for each commit Fastlane can assign a specific build number. And since you upload apps with incrementing Build number, it won’t be a problem that Version number is not changing.
When you’re about to release an update for the app I would suggest to:
1.) Increment the Version number (e.x. 2.4.2) in a new commit, push it to remote
2.) Create a Git tag for that commit
3.) Run your Fastlane lane which uploads the builds to Testflight
With the above technic, developers will not have to update Info.plist Version number all the time when submitting daily test builds to Testflight.
You only have to increment the Version number when you release an update - you can’t avoid this anyway.
Hope it helps! :)

Related

how to determine the current and future electron version(s) of vscode at extention build time

I'm collaborating on a vscode extension that uses a native module (#serialport) which needs to be included / pre-compiled for each platform/electron-version combination.
if we only include the current versions, it frequently breaks when vscode updates the electron version. some platforms can nativly re-compile , other can only after a (very) lengthy install of rather-complex toolchains that IMO should not be required for end-users.
So we want to include the relevant prebuilds,
and for that we need to look ahead in time ...
I'm looking for a reliable method to determine the electron versions used by vscode
- current version
- and the future (insider) version
- in addition it may be good to include a prior version to allow for backward compatibility
I have found that master/.yarnrc has the current ( or next imminent) version
today it is 4.2.7
vscode current release uses 4.2.5
prior versions can be read from the version history
master/.yarnrc
but what about the future / insider version ?
what is a good method/location to determine that programmatically ?, i.e. Which branch has the insiders version ?
Probable answer based on below hints and some more probing :
next version is in master ..microsoft/vscode/blob/.yarnrc
version 1.36.1 is in ..microsoft/vscode/blob/1.36.1/.yarnrc
version x.y.z is in ..microsoft/vscode/blob/x.y.z/.yarnrc
which only leaves the in-between versions/tags to be discovered.
intended approach:
during the build collect the relevant electron versions, ie "3.1.8","4.2.5","6.0.0-beta.0"
determine the ABI used by these versions using node-abi
var getAbi = require('node-abi').getAbi;getAbi('$version','electron')
use prebuild-install to download the relevant native prebuilds bindings, and include these as part of the extension
.\node_modules\.bin\prebuild-install.cmd --runtime electron --target $version --arch $arch --platform $platform --tag-prefix #serialport/bindings#
copy the bindings files for all ABI-arch-platform combinations to a folder, and inclide that in the vscode extension package
at load time , determine the ABI version of the running instance of vscode/electron, and dynamically load the module from the ABI/platform folder
alternative / additional approach:
- as a last ditch effort the code could try a just-in-time download of the pre-build binding file for the current platform, but this might run into permissions/malware scanner problems as that is essentially downloading downloading executable code from an external github repro.
current script code to download the bindings:
https://github.com/Josverl/pymakr-vsc/blob/fix/SerialMultiPlatform/scripts/mp-download.ps1
okay, so reverse logic then indicates that:
next version is in master https://raw.githubusercontent.com/microsoft/vscode/master/.yarnrc
version 1.36.1 is in https://raw.githubusercontent.com/microsoft/vscode/1.36.1/.yarnrc
version x.y.z is in https://raw.githubusercontent.com/microsoft/vscode/x.y.z/.yarnrc
which only leaves the in-between versions/tags to be discovered.

Build and Deploy pipelines with same version

I would like to specify the (SemVer) version number during a (not selfhosted) DevOps release, so that DLLs will have this version number embedded in them, and I can create a release to GitHub + NuGet with the same version.
However, I'm struggling with how to accomplish this with as much automation as possible.
I know I can use the /p:Version=x.y.z during build to set a specific version, but if I build one more time I shouldn't use the same version number again, which could be fixed by appending +buildnumber to the version. This build number is not something I neccessarilly would want in the actual release, though.
So, how should I best handle version numbers during build and deploy, without having to edit some variables every time?
how should I best handle version numbers during build and deploy, without having to edit some variables every time?
If you want to increment the version in build/release automatically, the buildnumber should be a good choice.
In generally, we defined the major.minor.patch in Variables or some config file, and use it with BuildNumber in the Build number format option:
Then, we could use the option use the build number as nuget version when we pack the nuget package:
For the release, we could use the parameter $(Build.buildnumber) to get the build number and set it as release version:
Now, we could handle version numbers with same version during build and release, without having to edit some variables every time.
Hope this helps.

Nuget packages versioning/update strategy

maybe someone has a good idea for the following scenario:
I have
prerelease dev packages, like that: packagename.1.2.0.1000-dev.nupkg
and
release packages, like packagename.1.2.0.1.nupkg
My idea was: starting at a higher number range for the dev packages would always allow getting the dev packages for developers if they enable the Pre-Release option at the nuget update step. This works fine.
Then later on I would like to update the project to the latest release version. But it seems there is no option to update to the latest release version that has a lower version number than the dev/pre-release package? Also the -Safe option doesn't seem to work here.
I can't keep the build numbers in sync also since these are different builds. If I have it the other way around, so higher build numbers for the release versions, it would never update to the latest dev packages if I do a normal nuget update, even including the pre-release packages...
Any idea here?
Thanks a lot!
Any package that is publicly available is a "release package" in technical/English terms. But the software industry has bastardized the language. So lets talk about stable (no prererelease tag) and unstable releases (prerelease tag).
The publisher history should be something like this:
1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**
If the publisher follows that pattern, then end-user clients can safely pull stable release bug fixes while developers can also pull unstable prereleases at their discretion.
You can also have something like:
1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**
It's a good practice to have separate feeds for internal dev/test, public prerelease and public stable releases.

Finding the latest build version of Library

I think I am missing something, but I want to add library from github to Android, I don't see anywhere on the Github page the latest built version of the library so I can include it in my gradle file. I have to go to maven or jetpack manually and search for it. Is there a shortcut? Am I missing something?
Thanks
There is a Lint check which allow Android Studio to query the latest versions available.
First you will have to activate this Lint Check
Go to Settings, then Editor > Inspections and search for Newer Library Version Available and check it.
Then run a code Analyze with Analyze > Run Inspection by Name... and type newer and select Newer Library Version Available
Run the inspection on the wanted scope (module only, full project, etc...)
Then you will see which library has a new version available.
PS
As stated by the Lint description of this feature, you should not let this check activated because it may slow your code analysis (query the repositories can take time)
You can use the + annotation to get a dynamic version. It can be use for the major, minor and patch part of the version. Ex :
// Major
compile group: 'org.mockito', name: 'mockito-core', version: '+'
// Minor
compile group: 'org.mockito', name: 'mockito-core', version: '2.+'
// Patch
compile group: 'org.mockito', name: 'mockito-core', version: '2.18.+'
But it's not a good practice to use such a dependency resolution.
Dependencies can unexpectedly introduce behavior changes to your app. Read your changelogs carefully!
The same source built on two different machines can differ. How many times have you said "but it works on my machine?"
Similarly, builds built on the same machine but at different times can differ. I've wasted so much time on builds that worked one minute
then broke the next.
Past builds cannot be reproduced perfectly. This makes it difficult to revert safely.
There are security implications if a bad actor introduces a malicious version of a dependency.

rails show the current version of my code on the page

On my website, in the footer, i want to clearly show which version of the code is live.
I am using git as version control. It would be great to get some visual feedback to know which version is actually live.
I want to show some readable number, like a gem version number. I could create a VERSION file, which i manage and increase every time it is needed.
I am curious if there are any existing solutions already out there? It would be preferable if it could e.g. use tag information from git.
I found a gem that actually does exactly what i need: version.
It allows to manage the version dead-easy, with the needed rake-tasks without the coupling to jeweler, and also allows to tag github in the process.
When developing a gem, i keep using jeweler, but for my rails-projects this is just what i need.
For more info see the gem's documentation.
Jeweler has some rake tasks that handle versioning pretty well for you. I have only used it for gems, but you can probably drop in a VERSION file and use the same rake tasks in a rails app. I have actually been thinking about doing the same thing for my app.. I will update this answer with more details if I get to it soon. For my gems I added a few new rake tasks that combine some of the jeweler tasks. Every time I have a new version I run one of the tasks and it increments the version (major,minor or patch), pushes my code to github and tags it all in one operation:
namespace :version do
desc "create a new version, create tag and push to github"
task :github_and_tag do
Rake::Task['github:release'].invoke
Rake::Task['git:release'].invoke
end
desc "bump patch push to github"
task :patch_release do
Rake::Task['version:bump:patch'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump minor push to github"
task :minor_release do
Rake::Task['version:bump:minor'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump major push to github"
task :major_release do
Rake::Task['version:bump:major'].invoke
Rake::Task['version:github_and_tag'].invoke
end
end
get jeweler if you dont have it and create a fake gem, put it on github and play around with the tasks until you get a feel for them. I took me a few tries (and peeks at the source) to fully understand what it was doing.
If you run these tasks every time you have a new version, your VERSION file will be in sync with your github project. If it was me, I would just read in the version number from the file and use something like settingslogic to set up a constant.. or you can set it up in an initializer. That way, you know that every time you restart your app, it will read the correct version