Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better story for different versions/flavors of a module #273

Closed
5 tasks done
vors opened this issue Jun 4, 2017 · 4 comments
Closed
5 tasks done

Better story for different versions/flavors of a module #273

vors opened this issue Jun 4, 2017 · 4 comments
Milestone

Comments

@vors
Copy link
Collaborator

vors commented Jun 4, 2017

Problem

Currently, platyPS doesn't have a way to re-use content between different version or flaivors of the module. I.e. https://github.com/PowerShell/PowerShell-Docs/tree/staging/reference has different top-level folders with a bunch of duplicated content.

The same thing is applicable for different flavors of the same module, i.e. Lync Server 2010, Lync Server 2013, Skype for Business Server 2015, and Skype for Business Online.

There is a significant overlap, so it's desirable to re-use the documentation.

Proposal

The schema would need to accommodate new meta information to support this.

  • Command level tag to indicate applicable module names and versions per cmdlet.
  • Parameter level tag for the same.

API to create and consume this functionality

  • New parameter for New-ExternalHelp that allows generating particular version out of tagged md
  • New capabilities for Update-MarkdownHelp that allows to update multi-version
  • * Maybe new cmdlet or param set for onboarding experience: easily combine existing md files for different versions into one.
@vors vors added this to the 0.8.0 milestone Jun 4, 2017
@vors
Copy link
Collaborator Author

vors commented Jun 4, 2017

To make it generic and simple to use, tags don't need to correspond to the module name or the version.
For both the parameter level and command level tags, they can be chosen as appropriate

For example

applicable: 3.0.0, 4.0.0, 4.1.0

Or

applicable: Lync for Bussiness 2016, Lync 2013

Then it can be scoped with a parameter New-ExternalHelp -ApplicableTag "Lync 2013"
Note that omitting applicable would mean "applicable to all version that can be generated out of it".
Which makes this schema changes incremental and doesn't require a schema number bump.

@vors
Copy link
Collaborator Author

vors commented Jun 5, 2017

First part of this work is merged into master, quick demo that explains the workflow https://gist.github.com/vors/d71009486ca95142653c7c29b8396123

@vors
Copy link
Collaborator Author

vors commented Jun 18, 2017

Merged to master

@vors vors closed this as completed Jun 18, 2017
@kenwith
Copy link
Contributor

kenwith commented Apr 10, 2018

@vors - never mind.. I deleted question about -ApplicableTag for the New-ExternalHelpCab after I re-read how it works. Ignore this. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants