{ "id": "63739", "key": "TIMOB-3107", "fields": { "issuetype": { "id": "2", "description": "A new feature of the product, which has yet to be developed.", "name": "New Feature", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [], "resolution": null, "resolutiondate": null, "created": "2011-04-15T03:37:10.000+0000", "priority": { "name": "Low", "id": "4" }, "labels": [ "cb-tooling", "core" ], "versions": [ { "id": "13505", "description": "Release 3.0.0", "name": "Release 3.0.0", "archived": true, "released": true, "releaseDate": "2012-12-14" } ], "issuelinks": [ { "id": "52604", "type": { "id": "10003", "name": "Relates", "inward": "relates to", "outward": "relates to" }, "inwardIssue": { "id": "120797", "key": "TIMOB-15415", "fields": { "summary": "CLI: iOS: Support to change BUILD property on iOS project", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "priority": { "name": "Low", "id": "4" }, "issuetype": { "id": "2", "description": "A new feature of the product, which has yet to be developed.", "name": "New Feature", "subtask": false } } } } ], "assignee": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "updated": "2018-12-12T08:11:27.000+0000", "status": { "description": "This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.", "name": "Reopened", "id": "4", "statusCategory": { "id": 2, "key": "new", "colorName": "blue-gray", "name": "To Do" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "Customers would like to be able to control the distribution build number that is created and tacked on to the version number on distribution. It is currently set to a UNIX TIMESTAMP but apple offers the AGVTool to modify the number and our community would like to be able to control the number through TiDev.\r\n\r\nSee tickets for reference:\r\n* http://developer.appcelerator.com/helpdesk/view/71611\r\n* http://developer.appcelerator.com/helpdesk/view/69721", "attachment": [], "flagged": false, "summary": "iOS: Controlling Distribution Build Number", "creator": { "name": "aleard", "key": "aleard", "displayName": "Alan Leard", "active": true, "timeZone": "America/Los_Angeles" }, "subtasks": [], "reporter": { "name": "aleard", "key": "aleard", "displayName": "Alan Leard", "active": true, "timeZone": "America/Los_Angeles" }, "environment": null, "comment": { "comments": [ { "id": "345565", "author": { "name": "iRonin", "key": "ironin", "displayName": "Cyprian Kowalczyk", "active": true, "timeZone": "America/Los_Angeles" }, "body": "According to [iTunes Connect Developer Guide|https://developer.apple.com/library/prerelease/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/UploadingBinariesforanApp.html] I should set a build number for the same app version like here:\r\n\r\n!https://www.evernote.com/shard/s2/sh/392ff7c1-ff94-4c94-a633-e28c2aeb8713/f2c9cb0d753df742038b0f30cbc0d12f/deep/0/Pasted-Image-10.03.2015,-10-06.png!\r\n\r\nAs far as I can see Titanium sets the build number to be the same as app version number but this is not how iTunes Connect prerelease system works. Each pre-release app version has to be review which cases delays in testing new builds; builds does not require reviews.\r\n\r\nIt is possible, but somehow undocumented and clunky, to control the build using the third dot in the version number so I have to set the version to `1.0.0.1` to have app version `1.0.0` and build number `1.0.0.1`.\r\n\r\nI think it should be at least documented.", "updateAuthor": { "name": "iRonin", "key": "ironin", "displayName": "Cyprian Kowalczyk", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2015-03-10T17:17:38.000+0000", "updated": "2015-03-10T17:17:38.000+0000" }, { "id": "345645", "author": { "name": "iotashan", "key": "iotashan", "displayName": "Shannon Hicks", "active": true, "timeZone": "America/Chicago" }, "body": "This is an excellent reason to give us control via tiapp.xml !", "updateAuthor": { "name": "iotashan", "key": "iotashan", "displayName": "Shannon Hicks", "active": true, "timeZone": "America/Chicago" }, "created": "2015-03-11T00:29:08.000+0000", "updated": "2015-03-11T00:29:08.000+0000" }, { "id": "393642", "author": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "body": "You can manually do this by setting the version in a custom {{Info.plist}} or {{AndroidManifest.xml}} file. Or you can automate it by writing a custom Titanium CLI plugin that ties into the hook system.", "updateAuthor": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "created": "2016-08-19T18:49:11.000+0000", "updated": "2016-08-19T18:49:11.000+0000" }, { "id": "393643", "author": { "name": "ingo", "key": "ingo", "displayName": "Ingo Muschenetz", "active": true, "timeZone": "America/Los_Angeles" }, "body": "[~cbarber] can you illustrate how to do this manually?", "updateAuthor": { "name": "ingo", "key": "ingo", "displayName": "Ingo Muschenetz", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2016-08-19T18:52:28.000+0000", "updated": "2016-08-19T18:52:28.000+0000" }, { "id": "393650", "author": { "name": "axmo", "key": "axmo", "displayName": "Alex Montgomery", "active": true, "timeZone": "America/Havana" }, "body": "As far as I can tell, for iOS, Studio builds set CFBundleVersion to a millisecond-precision timestamp, but CLI builds copy the value of the tag in tiapp.xml\r\n\r\nThis causes HockeyApp and Testflight to be confused about what the newest version is, if you happen to use both Studio and the CLI on occasion. (e.g. quick fixes over SSH while 'on vacation')\r\n\r\nIf the CLI could mimic Studio's behaviour by default, that'd be handy.\r\n\r\nMy manual workaround is to run:\r\n\r\n{noformat}\r\nnode -e \"console.log(Date.now());\"\r\n{noformat}\r\n\r\n\r\nand copy the result to:\r\n\r\n{noformat}\r\nCFBundleVersion\r\ntimestamp goes here \r\n{noformat}\r\n\r\nwithin the section of tiapp.xml.\r\n\r\nYes, a script could solve this. However, last I looked, the tiapp.xml npm module did not support CFBundleVersion, and the CLI should really should match Studio builds by default, no?", "updateAuthor": { "name": "axmo", "key": "axmo", "displayName": "Alex Montgomery", "active": true, "timeZone": "America/Havana" }, "created": "2016-08-19T19:24:24.000+0000", "updated": "2016-08-19T19:25:37.000+0000" }, { "id": "393651", "author": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "body": "[~axmo] We only add the timestamp for device builds and when you select {{iTunes Sync}} for the device (which is what is autoselected if there are no devices present): https://github.com/appcelerator/titanium_mobile/blob/master/iphone/cli/commands/_build.js#L3691-L3698.\r\n\r\nWe must insert this timestamp so that iTunes will properly overwrite the previous version prior to syncing. iTunes syncing should probably be ripped out since installing directly to device has worked for nearly 3 years and much faster.\r\n\r\nI'll get some examples as soon as I get a few minutes. Stay tuned.", "updateAuthor": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "created": "2016-08-19T19:33:37.000+0000", "updated": "2016-08-19T19:33:37.000+0000" }, { "id": "404106", "author": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "body": "Upon further investigation, my initial assumptions regarding this issue are incorrect. I interpreted this issue as simply wanting a unique or incremented build number for each build that would be displayed by the app, in a custom analytics payload or API call, or in debug logging.\r\n\r\nHowever, I now interpret this issue as wanting to change the actual version being injected into the Info.plist or AndroidManifest.xml. There currently isn't a hook that allows you to do that without messing up the differential build system.\r\n\r\nYou could write a hook that modifies the {{}} read in from the tiapp.xml, but the version is used in several places, so that's not a good idea.\r\n\r\nYou could write a hook that re-opens the Info.plist file and overrides the version, but you'd have to do it during the copy resource hook (and only first the first time) since you need to set the \"forceRebuild\" flag to true to invoke xcodebuild. This is super hacky.\r\n\r\nThe best solution is there to be a hook in the build that lets you modify the version.", "updateAuthor": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "created": "2017-01-04T22:44:50.000+0000", "updated": "2017-01-04T22:44:50.000+0000" }, { "id": "404109", "author": { "name": "axmo", "key": "axmo", "displayName": "Alex Montgomery", "active": true, "timeZone": "America/Havana" }, "body": "[~cbarber] For me, your initial assumption was *correct*. I'm looking for a way to automatically increment the values for {{CFBundleVersion}} and {{android:versionCode}} when I kick off a build, whether from Studio or CLI (for my purposes, having the value be identical across iOS and Android would be fine, but I expect some workflows would need each platform to increment independently)\r\n\r\nTo avoid unnecessary build number inflation, it might be best to limit the auto-increment to test and/or production builds.", "updateAuthor": { "name": "axmo", "key": "axmo", "displayName": "Alex Montgomery", "active": true, "timeZone": "America/Havana" }, "created": "2017-01-04T23:17:12.000+0000", "updated": "2017-01-04T23:20:13.000+0000" }, { "id": "444492", "author": { "name": "hknoechel", "key": "hansknoechel", "displayName": "Hans Knöchel", "active": true, "timeZone": "Europe/Berlin" }, "body": "+1 for auto-bumping these number - but only on production builds. Writing a tiny hook to do this should be doable, I'll give it a shot. Integrating this into the SDK may be useful for some devs, but maybe confuses some others. What do you think [~cbarber]? ", "updateAuthor": { "name": "hknoechel", "key": "hansknoechel", "displayName": "Hans Knöchel", "active": true, "timeZone": "Europe/Berlin" }, "created": "2018-12-11T16:43:14.000+0000", "updated": "2018-12-11T16:43:14.000+0000" }, { "id": "444493", "author": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "body": "[~hknoechel] Based on my comment above, apparently you can't cleanly implement this with hooks. We should probably just build in proper build number support. We need to figure out a few things before we do that:\r\n\r\n* Where is the build number stored? tiapp.xml? A dot file in the project dir?\r\n* Do we track build numbers per platform?\r\n* Do we enable this by default?\r\n* Do we allow projects to opt-out of build numbers?\r\n* Do we only increment for successful builds?\r\n* Do we increment for certain targets only? (i.e. do we only do build numbers for dist builds?)\r\n* How do we globally control build numbers across teams? Do we care that 2 people can generate different builds with the same build number?\r\n\r\nPinging [~cwilliams], [~eharris], [~jvennemann], [~gmathews], [~bhouse], [~jquick], and [~topener] to discuss if this is a good idea and what's the best way to do this.", "updateAuthor": { "name": "cbarber", "key": "cbarber", "displayName": "Chris Barber", "active": true, "timeZone": "America/Chicago" }, "created": "2018-12-11T17:06:22.000+0000", "updated": "2018-12-11T17:06:22.000+0000" }, { "id": "444503", "author": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "body": "Personally, I would only use a feature like this for automated builds. I wouldn't want it to auto-increment for builds on my own dev machine. (Maybe some devs would like this, but me, no.)\r\n\r\nAnd odds are existing apps already deviate by version between platforms. So, I think we should handle versions separately per platform. And it's near impossible to get an app version to line-up between app stores anyways because you may have to re-submit a new version when failing an iOS app review or if an unexpected bug is found. Lining up versions between platforms is hopeless. Especially if your Android app is being distributed to multiple Android app stores (Google Play and Amazon) because they often require separate builds to include different libraries.", "updateAuthor": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2018-12-11T19:47:55.000+0000", "updated": "2018-12-11T19:47:55.000+0000" }, { "id": "444524", "author": { "name": "jvennemann", "key": "jvennemann", "displayName": "Jan Vennemann", "active": true, "timeZone": "Europe/Berlin" }, "body": "I don't think we should implement a default behavior for this and rather just provide an interface for users to increment build numbers and let them write their own logic around it. As Chris already pointed out there are a lot of open questions around this and there are just too many factors to take into account. And as Josh said everyone might have different scenarios when they want or need to increment build numbers.", "updateAuthor": { "name": "jvennemann", "key": "jvennemann", "displayName": "Jan Vennemann", "active": true, "timeZone": "Europe/Berlin" }, "created": "2018-12-12T08:11:27.000+0000", "updated": "2018-12-12T08:11:27.000+0000" } ], "maxResults": 12, "total": 12, "startAt": 0 } } }