Make GitHub version checker public for plugins about xrmtoolbox HOT 17 CLOSED

👍

from xrmtoolbox.

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?

from xrmtoolbox.

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.

from xrmtoolbox.

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.

from xrmtoolbox.

👍 @daryllabar

from xrmtoolbox.

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.

from xrmtoolbox.

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

from xrmtoolbox.

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...

from xrmtoolbox.

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.

from xrmtoolbox.

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?

from xrmtoolbox.

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

from xrmtoolbox.

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 ;)

from xrmtoolbox.

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

from xrmtoolbox.

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

from xrmtoolbox.

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?

from xrmtoolbox.

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.

from xrmtoolbox.

Got it! Updated too!

from xrmtoolbox.