Make GitHub version checker public for plugins

[rappen]

I noticed the version checking in XTB and thought this could be implemented in plugins too.
It would probably be quite easy to make it a bit more dynamic (repo name, download url etc) and a public method that can be called from plugins that reside on GitHub and want to use it.
I also think it is possible to implement a markdown to rtf conversion to be able to display the release notes a bit nicer.
I'd gladly implement this if I get the chance :)

[shytikov]

👍

[shytikov]

I've seen that some code for markdown manipulation was checked in recently. But it should be adopted to work with plugins as well...

So we're talking about PluginBase extension that will check new version of current plugin, right?

[MscrmTools]

As checking for new version is source control system dependent, it should be implemented in IGithubPlugin and ICodeplexPlugin interface so that it would be possible to check on respective source control system for updates.

As for markdown display, I added something to format it correctly. Well, at least, the maximum I can do since github markdown seems to be a specific implantation of markdown.

[daryllabar]

This brings up an interesting design decision. I created the ICodeplexPlugin and IGithubPlugin for the toolbox to be able to show ratings of plugins. This requires the developer to declare and implement the interface. Ideally (IMHO) we would create an IVersionChecker (or preferably some bettered named interface, naming things is hard), that both ICodeplexPlugin and IGitHubPlugin can implement. That way the calling code just cares that it implements IVersionChecker, not if its an IGitHubPlugin or an ICodeplexPlugin, and if someone manages to host something on their own public website, they could still implement the interface.

[rappen]

👍 @daryllabar

[daryllabar]

It sounds like @rappen is talking about creating an abstract GithubPluginBase for the toolbox that implements version checking automagically, and a way to display release notes.

I like the idea but thought it would be a good idea to brainstorm where that will lead us to. It might be better to have some other class that performs the actual version check logic besides the Plugin itself. the Plugin can expose a property of the class, but it doesn't have to be able to implement the interface itself. The beautiful part about the PluginBase is we can change the IPlugin interface and as long as the PluginBase provides an implementation, no one who inherits from the PluginBase will break.

[shytikov]

Jedi mind tricks shell perform I, so it will be abstract GithubPluginBase that extends PluginBase and implements IGitHubPlugin?

[daryllabar]

Unless we want to do some other class that the plugin base can expose as a property. That way if a plugin doesnt inherit from plugin base, they could still potentially reuse your logic...

[skfd]

My advice is to allow impementing IUpdatable interface. This interface will require one field -- Github repo and a branch name. This branch should contain plugin.json with semver version.

Autoupdate does not have to be mandatory.

[MscrmTools]

Are you saying that we should only support Github as a repository for XrmToolBox plugins? I have the code to check a new version on CodePlex but what if other repositories are used?

[skfd]

It could be different well known code hosting sites, I'm just suggesting a principle of version detection.

[rappen]

IMHO I think the basic solution @MscrmTools (and me) is using by having a naming convention for the tag_name field on the release is quite good enough. It worked with CodePlex, it works with GitHub, and it is OOB in that sense.
The level of abstraction / interfacing is another question, my first approach would have been to just expose the existing method as public and adding parameters to look up the repo...
Might be a bit "unfancy", but works ;)

[shytikov]

I would put ourselves to @rappen's hands as soon as he has an active request for this feature. 💯

[rappen]

I will probably not have the time to implement this in near future. Making my own version of this in FXB until we have a common way of handling this.
I will implement it in a more generic way though, by adding user and repo as input parameters to the version checker.
Commit for FXB here: rappen/FetchXMLBuilder@c5cc598

[MscrmTools]

About this one, I can expose the class publicly.

I just noticed that I check for any new version, even if it is a prerelease. Do we agree I should check only for release and not for pre release as well?

[rappen]

Agree. Only Release.
I guess only github-user and -repo is necessary as parameters to the public method. I also noticed the download link was static, not based on user/repo.

[MscrmTools]

Got it! Updated too!