Some questions about the roadmap before I submit a PR

[riverar]

I'm preparing a PR to make some minor changes to the roadmap to better align it with public terminology (and fix a few typos). Before I do, however, I have some questions:

1. What does Framework Package support for Unpackaged apps mean? Is this referring to PSF support? Or an implementation detail of generally supporting Reunion in unpackaged apps leaking out?
2. Earlier in the roadmap (0.5), WinUI is slated to be supported in packaged applications. What about unpackaged apps? Is that supposed to be encompassed by general full Reunion support in unpackaged applications via 0.8?
3. When will Windowing/AppLifecycle specs make their way into main branch? They're on the roadmap but haven't even been checked into main yet, which is a bit strange. It's my understanding that the merge into main is what should generally trigger community review, right?
4. Who let @tfennel in here?

[BenJKuhn]

Let me see if I can answer / find answers.

1. MSIX Dynamic Dependencies #393 - dynamic dependencies, which is the ability for a non-packaged app to indicate that it wants to add a framework package as if it had an MSIX dependency on it.
2. @MikeHillberg or @Scottj1s might be a good person to comment.
3. @aeloros, can you take this one?
4. There's just no stopping him. He's a machine.

[BenJKuhn]

Good call-out. Framework packages date back to win8, and nearly every packaged app uses them, but it's an implementation detail that's largely automated for most apps (this is how MISX-packaged apps access the C runtime, for example). MSIX framework package is the new name for Appx framework package, which has a brief description in the glossary on the wiki. There's a bit more about them on docs.microsoft.com, but not a lot.

I'll keep this in mind as I put together more documentation. Given the dearth of information out there, I did update the glossary a bit, but more needs done.

[aeloros]

For "3" above, this could just be some misunderstanding on my part of the workflow in GitHub. There is a chance it could also be due to the granularity used by us to track these features. I'll explain the current state below, and you can tell me where I've gone wrong at least for the AppLifecycle stuff.

Launch, File, and Protocol argument paths are in and should be in main with tests. This is the implementation, and while you specify 'spec' above I have to believe you mean the code?

I'm working on the Startup launch type next, and then moving onto App Instancing APIs. Again, the code and not any spec documentation.

@andreww-msft might have a better idea for functional specification documents, as I believe he's been focusing on that.

I'm unsure if it's specifically the Spec part (see Andrew) or maybe I'm not resolving something since only parts of it are finished (granularity problem).

Did this help clarify anything?

Thanks
--Scott

[riverar]

@BenJKuhn Got it, thanks. So examples being vcruntimes and such. I understand why this is on the roadmap now, ha.

@aeloros We have code showing up and a roadmap entry but no corresponding specification committed into main under specs (https://github.com/microsoft/ProjectReunion/tree/main/specs). How do you know what to write? 🙂

It appears the related proposal still has unanswered questions (#111) and the spec is still in development, at least per the Project board (Spec in Progress column).

Am I off base here?

[aeloros]

I don't think you're off base. I think you have found an instance where our process has been evolving. The proposal is fairly stale I think, and is being worked on by Andrew in his private branch (https://github.com/microsoft/ProjectReunion/tree/user/andreww-msft/specs). I was talking to him earlier, and we think that issue should be resolved when he commits his PR for the spec to integrate to main.

Thanks
--Scott

[Scottj1s]

Yes, for (2) - unpackaged apps are scheduled to be supported by 0.8