Best practices to keep app up to date with new WTS developments after generation

[hansmbakker]

trafficstars

WTS is constantly updated. This means that the generated apps will get better or can do more.

Are there any recommendations, besides generating an app again and manually comparing differences, as to how to keep an app up to date with new developments in WTS after it has been generated?

[sibille]

You can add new pages and features using the context menu on projects generated with WTS, as described here: https://github.com/Microsoft/WindowsTemplateStudio/blob/dev/docs/getting-started-extension.md#public-release-instructions

If we introduced breaking changes with the new version of WTS regarding to your project, you'll see a yellow warning message, that contains a link to instructions on how to update your project.

Is this what you were looking for? Is there anything else we could do/you'd expect?

[hansmbakker]

I didn't mean new page types, but more like when there are structure changes or bugfixes in the core of the generated apps.

E.g. when you replaced the NavigationView code. Or e.g. you're moving to a multi-project approach now. Or say that you move from Prism 6 to Prism 7 (which could be a breaking change).

What are then the best ways to quickly find the required changes to make to our apps? (since we probably cannot easily re-generate an app and add our own existing modifications to it?)

[crutkas]

@hansmbakker these are great suggestions. How would you suggest we would do this knowing people on different versions, frameworks and languages.

Typically a lot of our adjustments such as multi-project support is something a dev would do naturally based on their needs. Same with updating from Prism 6 to 7, that guidance i would imagine would actually come from the Prism team, as they are the experts in Prism.

For NavView, I thought we did but looking at https://github.com/Microsoft/WindowsTemplateStudio/blob/dev/docs/projectTypes/navigationpane.md doesn't seem like we did, great feedback.

[hansmbakker]

@crutkas I agree that developers could do it themselves, but the reason I wondered was that WTS is positioned as a "one stop shop for best practices". Of course developers should still think themselves, but it would be nice to have a way to keep up to date.

[hansmbakker]

For NavigationView you're right --> there is a folder with documents https://github.com/Microsoft/WindowsTemplateStudio/tree/dev/docs/projectTypes/updatetonavigationview.

[hansmbakker]

Without thinking how to practically implement it, it would be nice to be able to keep own modifications separate from a core that would be maintained by WTS.

A possible (maybe too complex?) solution could be to:

• use a kind of recipe for the core application that could be easily re-generated with the same settings as the previous time (framework choice, app style choice, app name)
• have this core application as a kind of tagged version on a 'core' branch in your git repository. Every time you re-generate your app it is tagged there.
• having your own changes in another branch which bases upon the 'core' branch. After you regenerate your app you can then rebase on the 'core' branch

[crutkas]

Rebase is hard when we do massive changes (like multiproject). Regenerate is a good idea however BUT where would you want the core team to prioritize is the big issue

I think if this is a feature you would want to implement, let’s create a new issue and do some proper spec / implementation discussions.

[hansmbakker]

Yes, I understand. It was the first mechanism that came to mind.

I mostly created this issue to hear your point of view on keeping up to date with new developments. If documenting the biggest changes is the way to go, that's also an outcome. As for me, implementing this feature would not be something I could commit to on my own.

[crutkas]

@hansmbakker you raise a good idea but if you had to prioritize stuff, would you rather have us add in new stuff or this?

[hansmbakker]

I wouldn't say this is a must have immediately. I was just curious whether you have a view on this.

In general if you're asking me, then that would depend on

• how much time it would take to develop ( = how much other new things would be postponed)
• what other (new) things there are on your backlog
• what the core team / other users say

[crutkas]

here is the next two releases for roadmap :) https://github.com/Microsoft/WindowsTemplateStudio/blob/dev/docs/roadmap.md

Identity, unit tests, menu bar nav pattern, database, some housekeeping (refactoring our core / wizard) and VS 2019 support are our big items.

[hansmbakker]

Well, those all look like good points, too. To me it feels difficult to prioritize as long as there is no rough proposed solution direction to the question, and therefore it's difficult to estimate the impact.

[mrlacey]

WTS is positioned as a "one stop shop for best practices"

Where? By whom?

---

Where breaking changes in 3rd party libraries have been encountered previously, specific documentation has been created for this. (Here's an MVVMLight breaking change doc.) That doc explains the manual changes necessary to keep adding to a project with WTS. When adding to a previously generated project that used the old version, the link to the docs is displayed in the New Item wizard.
Discussions have already taken place to confirm the intent is to use the same approach for future Caliburn.Micro and Prism library changes.

---

The move to a multi-project solution is probably the biggest single change to WTS and there is nothing of similar complexity on the roadmap.

Just because WTS now generates a multi-project doesn't mean that you must update any previously generated projects to do so. If you want to, there are instructions here. Putting platform agnostic code that has the potential to be reused in a separate library was a best practice long before WTS existed. It was a purely technical limitation of the tool that everything was previously put in a single project.

---

Lots of thought and planning goes into everything that is included in WTS to attempt to minimize any possible issues due to future changes. This is also the reason that some things have been on the backlog for so long--we've heard that changes are coming so we're waiting to implement them in their future form, rather than have to deal with the consequences of having to make changes in the future and deal with different versions "in the wild".

In terms of an actionable change based on all the discussion above, there's still a scenario that hasn't been discussed but probably should be: fixing bugs. The generated code can broadly be grouped into two classifications:

1. that which developers are expected to change.
2. that which should never be touched.

If a bug is found in code in the first group the impact is not very large. We can change the templates to fix future apps and that's probably good enough. However, if bugs are found in the code that is expected to never be touched, how should this be communicated with people who have previously generated apps that contain the bug? At the very least I think there should be a list of such errata documented somewhere.

[mikebattista]

Assigning to revisit how we handle breaking changes going forward.