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 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.
Created attachment 16013 [details]
A workbook that makes a compelling (I think ;)) case for using YAML
Attached is a workbook that makes the case for using YAML for workbook metadata,
including sample code and metadata, how it's read and how it can be trivially
converted back to JSON to drive whatever internals we have currently that
depend on the JSON metadata present in current workbooks.
Maybe it should be pretty straightforward to even support both ;)
The first few paragraphs make the case as follows:
Workbooks are great because you can just upload them to GitHub and have people collaborate
even just using a brower: update, send pull requests, merge, comment on lines, etc.
Anyone who has used Jekyll (meaning anyone who has used GitHub Pages) is likely familiar
with Front-Matter, which basically is markup at the begining of the document which is
distinct from the rest because it uses a totally different markup:
title: Blogging Like a Hacker
The front-matter isn't just more readable while editing the text file, it's also
rendered nicely by GitHub itself, as can be seen here https://github.com/kzu/sandbox/blob/master/YamlFrontMatter.md
That markdown document is the YAML-ized version of the attached workbook itself, so you can
see how much better it is in GitHub ;)
Created attachment 16014 [details]
This workbook actually loads (fixed typo)
Created attachment 16015 [details]
The one with the missing HttpClient dependency
For what it is worth, I like this idea, purely on the github grounds.
We would have to keep both file readers in place, as the last thing I want to do is break existing workbooks, even the handful that exist out there.
And start using the new file format for the new ones we produce.
I agree, also purely on the Github grounds. We would absolutely implement this with backwards compatibility in mind.
Maybe on read, we support both, and on write, we emit the YAML version (since going from one to the other is really straightforward from the code point of view). Supposedly, JSON is a valid subset of YAML.
Yes, we would migrate any JSON manifests to YAML. JSON serialization would be removed while deserialization would be kept for migration to YAML.
This is implemented in master and will be in the next release.