Great to see you guys work on quality. Why wait until May to deliver performance enhancements? I'd address those first instead of spending time on bindable picker, accessibility, macOS, embedding, etc. Regardless, the list looks good.

@AdrianKnight said:
Great to see you guys work on quality. Why wait until May to deliver performance enhancements? I'd address those first instead of spending time on bindable picker, accessibility, macOS, embedding, etc. Regardless, the list looks good.

Thanks @AdrianKnight! I hear you. Performance is hugely important and it's happening. It's easily among the first things I hear when talking to anyone about Forms, and be assured we'll continue beating that drum so it gets all due focus.

I also look forward to those performance improvements. They sound promising.

Will there be a 2.3.4? Only yesterday somebody asked again what happened to 2.3.4-pre1. It has been removed right after the release and nothing new within 4 weeks. I saw several bugs which say "fixed in 2.3.4-pre1", but that version is not available.

If you skip 2.3.4, then when will we see 2.4.0-pre1? If it should be released in February, then a pre version should be imminent now.

+1 for CarouselView. Finally someone can take a look at my simple pull requests #9#10. The project is also far too complicated (the .bat file build proccess?) for a person (like myself) to contribute to easily

Thanks a lot for the list, makes sense to me! Very happy to see the performance as top priority!

Please note there is quite a big backlog of small bugfix PR's done by @AdrianKnight for example. Ideally, I think the number of open PR's should be as low as possible. How does reviewing and validating PR's fit in the Roadmap?

After review and approval, will the PR get a badge for the intended release when at latest it will be merged? Then there is a deadline per PR and for the submitter it is clear when a merge is expected.

@MichaelRumpler@BradChase.2654 I'm looking into this today. My understanding right now is we have addressed all blockers to pushing 2.3.4 out as a pre and getting everyone banging on it again.

Keep in mind, this roadmap is specifically feature releases in the broader scope and doesn't encompass every detail of the Forms release world. As I codify other processes and release plans, I'll get those out here in another thread and likely on GitHub so we have visibility and discussion and set clearer expectations.

@DavidOrtinau My understanding from what we noticed is you still cannot add Event handlers into XAML with the latest version of forms with XAMLC turned on. There were alot of issues with the latest XAML reader...

EDIT: That reminds me to ask if these changes to the forms team are going to include some sort of an internal testing phase with a team dedicated to testing? Along with that will there be a serious attempt at trying to figure out issues rather than just," I tried it in 5 minutes and could not reproduce, please enter an entire project in bugzilla and we might look at it" answer we typically get? I think that would show that you are dedicated to the community and the Forms project...

@AndrewMobile thanks! I'm in favor of leveraging GitHub for wiki and roadmap etc.

In drafting our roadmap, I referenced several others. Anything like that that you think would make the Roadmap more useful, I'll definitely entertain it. It's not a marketing piece, it's to increase visibility with the community about what's being done and planned. Not everything will make sense to include on the feature roadmap, but if it's something we need out there, I'll find the right place for it.

re: branches - commits and PRs in GitHub is where the most recent stuff lives and we are moving towards that everywhere possible. Which means, there's some stuff that predates or is spiked on the side and not reflected yet in the main repos. I'm getting a grasp on that and I think it's fair to ask "where's the work" and "when can we expect to see progress".

@bprasad said:
Also solve Issue with vs and make xaml previewer more strong ....most problem I face is designing the page...

For sure, we can all expect XAML Previewer to only get better as it approaches release. You may already realize this, but although it's in the Stable channel, it is still a Preview release. We should try to get some kind of badge on it to make that clear.

@DavidOrtinau - This might be a question for the Test Cloud team, but is there any update on when Xamarin.UITest will support all Xamarin.Forms supported platforms? I'm holding off on any further UITest work until I can use one set of tests across Android, iOS and UWP. Obviously, support for WinRT would also be useful too, but UWP is more important for me.

@JohnHardman said:@DavidOrtinau - This might be a question for the Test Cloud team, but is there any update on when Xamarin.UITest will support all Xamarin.Forms supported platforms? I'm holding off on any further UITest work until I can use one set of tests across Android, iOS and UWP. Obviously, support for WinRT would also be useful too, but UWP is more important for me.

Yeh, that's really a TestCloud discussion. I'll see what details I can get regardless.

@bprasad said:
Also solve Issue with vs and make xaml previewer more strong ....most problem I face is designing the page...

For sure, we can all expect XAML Previewer to only get better as it approaches release. You may already realize this, but although it's in the Stable channel, it is still a Preview release. We should try to get some kind of badge on it to make that clear.

Can I expect the previewer will work in Visual Studio for android without a Mac connection? I was so surprised when learned an Mac is needed currently.

Can I expect the previewer will work in Visual Studio for android without a Mac connection? I was so surprised when learned an Mac is needed currently.

[EDIT] Pierce just told me I might be wrong about this. What?! Grabs pitch fork. I'm being told there's a fix and it's coming. Let me find out more and I'll report in another thread since Previewer isn't really on topic. [/EDIT]

I think you're fine. Mac is required when doing iOS development. If you're doing Android on Windows and using Visual Studio you are fine. Here are some good resources about the XAML Previewer:

A while ago, I outsourced (at my own expense!) development of drag & drop functionality for use in my first app. There's still work to be done (the biggest bit is that UWP is not working currently), but the code so far can be found at https://github.com/johnshardman/XF_DragAndDrop

If nothing else, it shows that it can be done (subject to getting it working on UWP). Any chance of the Xamarin.Forms team taking this over, completing & enhancing, to get it built into ListView at some point in future, even if a fairly distant future?

This is probably not the correct place, but I couldn't find any other info about the MenuPage in the evolution forum or the github pull requests.

The MasterDetailPage can use the Master as a flyout so that it overlaps the Detail or they can be shown side by side when you use MasterBehavior=Split. Then the Detail width is not the full page width.
What I am missing is that the user can swipe in/out the Master and the Details width is adjusted to be the rest of the page. The two pages should not overlap, but the user can still decide whether he wants to show the Master (Detail has less space) or not (Detail has full width).
Maybe you can design the MenuPage so that it supports this (or enhance the MasterDetailPage).

Where would be the proper place for this? In the evolution forum? In UserVoice? In the forms-devel mailing list? In Bugzilla? I still don't get the difference. You have too many tools!

A while ago, I outsourced (at my own expense!) development of drag & drop functionality for use in my first app. There's still work to be done (the biggest bit is that UWP is not working currently), but the code so far can be found at https://github.com/johnshardman/XF_DragAndDrop

If nothing else, it shows that it can be done (subject to getting it working on UWP). Any chance of the Xamarin.Forms team taking this over, completing & enhancing, to get it built into ListView at some point in future, even if a fairly distant future?

@MichaelRumpler said:
This is probably not the correct place, but I couldn't find any other info about the MenuPage in the evolution forum or the github pull requests.

The MasterDetailPage can use the Master as a flyout so that it overlaps the Detail or they can be shown side by side when you use MasterBehavior=Split. Then the Detail width is not the full page width.
What I am missing is that the user can swipe in/out the Master and the Details width is adjusted to be the rest of the page. The two pages should not overlap, but the user can still decide whether he wants to show the Master (Detail has less space) or not (Detail has full width).
Maybe you can design the MenuPage so that it supports this (or enhance the MasterDetailPage).

Where would be the proper place for this? In the evolution forum? In UserVoice? In the forms-devel mailing list? In Bugzilla? I still don't get the difference. You have too many tools!

Yes, we want to have those kinds of conversations in the Evolution forum. We need to get our thoughts out there as we did yesterday with Accessibility so it's not just a mention on the Roadmap. And we didn't want to further delay the Roadmap. So, give me a bit to make that happen.