A made a fastlane script to make test flight builds and let's say that at the moment I am working on version 2.5.4 of my app, which is in the app store.
I need to do the following things, in order:
Make a test flight build for 2.6.0, and have it tested
Update the test flight version 2.5.4 by making a new build and have it tested
Make a test flight and an app store build for 2.5.5
Resume with 2.6.0, make new test flight builds and release it
Now the problem is that the script always fails if I don't increase the version. I didn't try to do it because I am afraid that it will not be possible to go back. Question: if now I make a test flight build for 2.6.0, will it be possible to go back to 2.5.4/2.5.5 or I will be able to change the version only sequentially?
First to make sure we're talking about the same thing:
The AppStore App Version should be 2.6.0 and it has nothing to do with the "testflight build" version. The user sees version 2.6.0 in the application but does not know which build you are using in the background.
Once you upload a "testflight" build, you cannot delete it and you cannot upload another with the same version number, and that is your problem as far as I understand.
What would I do in your place ->
Increment the build number, not the version number, so you can upload the build to testflight and not have to worry about being able to revert to a version.
I am not sure about the answer to your question, but as far as I know you can go back to the old version, you just cannot upload the same version twice.
Related
I have completed build automation of Eclipse RCP application using maven/tycho.
Now I want to make it more seamless. So I am checking if we can auto-increment application version with every build.
for e.g. As you can see in attached picture, snapshot of .product file. enter image description here
Version is 1.2.0. So with every build, it should increase the version number 1.2.1, 1.2.2, 1.2.3, and so on, without changing the version manually in product file. Once I execute the parent pom(trigger the build), it should also increment app version and complete
the build process, all in one command that is mvn install.
can we achieve this using maven/POM.xml or please suggest any other solution??
You can use the goal parse-version of the org.codehaus.mojo:build-helper-maven-plugin (documented here: https://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html). This will store the parts of the current version in some properties (by default, parsedVersion.majorVersion, parsedVersion.minorVersion and parsedVersion.incrementalVersion). You can use such information to compute the next version number as you see fit.
Then, since you are using Tycho, you can pass these properties appropriately to the goal set-version of the org.eclipse.tycho:tycho-versions-plugin (https://tycho.eclipseprojects.io/doc/latest/tycho-release/tycho-versions-plugin/plugin-info.html).
Here you can see a simplified example using these two goals to remove the -SNAPSHOT and .qualifier: https://www.lorenzobettini.it/2020/02/remove-snapshot-and-qualifier-in-maven-tycho-builds/.
As I said, in your case, you'll have to do a few more operations to compute the next version number.
Xcode 11 has changed the way that versions are handled.
So far I had two targets, Dev & Prod, each with a separate versions. Prod version would be entirely manual, Dev would be automated:
During a build, a script would run, which then would fetch git tags. One tag would contain information about the latest Dev version. If it's newer, it would update version inside Info.plist just for the Dev target
When Dev would be deployed using a script (create an ipa, resign for in-house distribution, upload), the build version would then be increased. Remote tag containing version information would then be updated
In this way everyone's dev version would get automatically synchronized and managing multiple dev builds would be be easy. Prod would be updated relatively infrequently so it can be managed manually.
However, in Xcode 11 whenver version (or build) is updated inside the General tab, entries in Info.plist are replaced with $(CURRENT_PROJECT_VERSION) and $(MARKETING_VERSION) and Current Project Version and Marketing Version inside the build settings tab is used instead.
So far I would use PlistBuddy in order to read and update versions inside Info.plist, but from what understand now I'd have to use agvtool. However, there are two issues with it:
If it's ran as a Run Script phase, it causes the build process to cancel
It is unable to handle separate versions for two targets (so I cannot just automatically manage Dev, while leaving Prod alone)
I know that theoretically I can still use Info.plist for versioning, but the moment someone changes version manually in the General tab, the whole thing will get messed up (from experience I know that this will happen).
I have two questions:
Is my understanding of the process correct?
Can still have a version management system using agvtool similar to what I had before?
I did my build numbers as 1, and then 2.
Does this matter - is it just a mater of preference as to how you do them?
The Build Number (or CFBundleVersion) is not shown in the App Store so for the user it does not really matter.
The purpose of the Build Number is that developers can distinguish different builds using the same Version (CFBundleShortVersionString).
Consider you are working towards a version 2.1.0. Before you publish this version on the App Store, you probably want to distribute Beta builds to testers. If they report any issues and you fix them, you will need to create and upload a new build but probably still use the version 2.1.0. In that case you would use the Build Number to distinguish the two version.
You can use whatever you like as a build version. Apple provides a tool to increase the Build Number in Xcode projects named agvtool.
Another way (and what I personally do) is to use the git commit count as the Build Number. This can be automated via a Build Phase. That way, every change that you make (and commit) automatically increases your Build Number.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.
We are using Jenkins to run our xcodebuilds on a Mac Mini server. In the last weeks we started development of iOS 7 apps and we installed Xcode 5 DP versions on the Mac Mini.
When installing a new Xcode version and configuring the xcodebuild of the new Xcode which xcode-select this new version is also used for building our old iOS 6 apps - which breaks the UI of them.
Is there a way to tell Jenkins which xcodebuild it should use to build a project?
Check out the solution posted by Andy Molloy at http://andymolloy.net/specifying-xcode-version-for-jenkins-projects.
You have to install EnvInject plugin for Jenkins and add DEVELOPER_DIR=/Applications/Xcode5-DP6.app/Contents/Developer environment variable to your build job.
It doesn't look like it is possible to specify xcode version per jenkins job. Also switching xcode version on the command line requires root permissions.
You might manage to solve your issue by making sure your IOS 6 apps, when built with the new xcode, work properly. Try selecting the proper base SDK and deployment target http://www.clarkcox.com/blog/2009/06/23/sdks-and-deployment-targets/
If that won't work you could try forcing a switch of the xcode version to use at build time, pre xcode plugin use. You will have to fiddle with sudo rights. Given that this is a system setting, you might need to prevent multiple builds from happening simultaneously.
I would do my best getting the multiple builds working with a single xcode version though.
Select the xcode version at runtime
Use EnvInject plugin
for jobs that require the non default do something like
DEVELOPER_DIR=/Applications/Xcode6.0.1.app/Contents/Developer
under Inject environment variables to the build process
https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin