Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Description of Problem:
Our TestFlight notes are cumulative until we release to the App Store. When different developers release to TestFlight by filling in the API keys and add the release notes, neither of these elements are included when the solution is Committed to Source Control. When another developer does an Update from SC, the TestFlight API keys and release notes are missing/incomplete. The API keys and Release Notes that were last maintained locally are presented.
Further, the TestFlight API keys and Release Notes are tied to the Build Profile. When the build profile is changed from Debug -> Release and visa versa, the API keys and Release Notes disappear. Sometimes, we deliberately switch to the Release profile and deploy to TestFlight to see how TestFlight will operate when we release to the App Store.
Steps to reproduce the PROBLEM 1:
1. Add API Keys and Release Notes to TestFlight deployment dialog window and deploy to TestFlight on workstation A.
2. Commit changes to SC on workstation A
3. Update solution on workstation B.
4. On workstation B, go into TestFlight deployment dialog window, new Release Notes from step 1 on workstation A are not present.
Steps to reproduce the PROBLEM 2:
1. Set build profile to Debug.
2. Fill in API keys and Release Notes and deploy to TestFlight.
3. Change build profile to Release.
4. Go into the TestFlight dialog window, the API keys and Release Notes are blank.
Actual Results PROBLEM 1:
TestFlight API keys and release notes are stored locally and are not updated with changes from other developers after Updating from the central repository.
Actual Results PROBLEM 2:
It appears that switching build profiles loads a different set of TestFlight profiles.
Expected Results PROBLEM 1:
TestFlight notes (+ API details) should be checked in with the solution into SC so all developers inherit any changes.
Expected Results PROBLEM 2:
Irrespective of the build profile, the TestFlight API keys and Release Notes should be consistent.
How often does this happen PROBLEM 1?
Whenever changes are made to TestFlight details from any workstation.
How often does this happen PROBLEM 2?
Whenever the build profile is switched.
1) As I understand it, TestFlight API tokens are per user. So although it might make sense to store the team token in the project file, it would not be appropriate to share the API token between users. And the TestFlight API is extremely simplistic and does not allow us to enumerate any user information, so I don't currently see a good way to provide a better experience in this regard, unfortunately.
Also, I don't think project file isn't really the appropriate place to store the release notes either, they're not really a property of the project.
2) This is one of those things where no choice will please everyone, some people do want to be able to have different release information for different configurations.
1) Seems to me that Release Notes *should be* a property of the project (or perhaps the configuration?). Not sure where else would make more sense to put them. Certainly shouldn't be a per-user property.
Not sure what to do with the rest of the issues listed.
I would be happy if the Release Notes were tied to the project and were automatically checked-in with other changes. It would be
I guess I can live with the API keys being missing.
However, there shouldn't be different set of values for all of these things when switching from Debug to Release. TestFlight doesn't make a distinction so there is no need for separate release notes and keys for the different build profiles.
Well, my main reservation is that the project file is supposed to store settings, not data. Perhaps we could have some kid of ReleseNotes.txt?
Sure. I don't particularly mind. My only concern is that it gets automatically included in the set of files that gets checked-in to source control so that when other workstations Update the solution from source control, the latest version of the release notes come down with it.
I just upgraded to 4.0.12 today and all of the Test Flight info disappeared - all of the keys and release notes.
Could I get a status update on this please?
I'm sorry, I haven't had time to work on this. I've been busy with implementing all the things we'll need when Xcode5 is released (unfortunately, it looks like Xamarin Studio will have to do all of its own provisioning profile management).
I'll look into this Test Flight stuff as soon as I get a chance.
Thanks for the updated Jeff.
I've implemented the Release Notes text file approach in git master
I have checked both issues with following builds:
X.S 4.2.3(build 24)
I have observed that:
1. When configuration is set to debug and user Publish to Test Flight after entering Key, Release notes and then change configuration to Release. Publish to Test Flight dialog does not display entered Key and Release note.
2. When user publish project to Test flight from Workstation 1 and then publish same project to test flight from Workstation 2, then I am not seeing Release note which was used from Workstation 1.
Please let me know is it correct build on which it has implemented?
Also please let me know are both options has implemented?
You need to create a RELEASE-NOTES.txt file and add it to the toplevel of your iOS project.
Today we have checked this issue with following builds :
XS 4.2.3 (build 35)
As per comment 13, we are getting same behavior as shown in screencast.
Screencast : http://screencast.com/t/sjmXqgNrVsJ
Hence closing this issue.