Display version numbers for the plug-ins and what Gitbucket version they require.

gitbucket-plugins / gitbucket-plugins.github.io

gitbucket-plugins community site

http://gitbucket-plugins.github.io

13 stars 4 forks source link

Display version numbers for the plug-ins and what Gitbucket version they require. #4

Open aadrian opened 8 years ago

aadrian commented 8 years ago

Hi,

Please display version numbers for the plug-ins and what Gitbucket version they require. The users loose just too much time trying to fit the pieces together.

Thank you.

McFoggy commented 8 years ago

@aadrian the plugins have their own lifecycle, so if project maintainers don't provide this information it has to be provided by the community. Do not hesitate to submit PR to the documentation of those projects.

aadrian commented 8 years ago

the plugins have their own lifecycle,

That is logical. But they should be enforced to display their own version number and also the version number of the GitBucket it was working with. This is the only way to keep things sane.

Right now, without this, it would appear that everything is compatible with everything, and this is clearly not the case.

McFoggy commented 8 years ago

@aadrian I saw you opened issue 931 on gitbucket that should allow plugins to expose their comaptivility version. Then we could enhance gitbucket screen to show that information somewhere in the plgin screen. But for this gitbucket plugin community I do not see an easy way to enforce that. Perhaps we can think about a mandatory/required file descriptor for each plugin project that could be read by community site ; for sure it is not trivial to know & expose the compatibility upfront.

aadrian commented 8 years ago

Perhaps we can think about a mandatory/required file descriptor for each plugin project that could be read by community site

IntelliJ is doing exactly this for their plug-ins :).

Even more, the use "release ranges" that are tied to API compatibility, so that a plug-in can be compatible with more distributions as long they're in range.

McFoggy commented 8 years ago

I thought a little bit about this, but it is not as easy as that because of the site structure.

Currently I see 2 problems to solve the usecase:

Unless github serve raw content using CORS, we could not read the plugins descriptors from the community site Javascript
as the site is static (built by jekyll as many other pages), I do not know a way to collect remote data during build phase

aadrian commented 8 years ago

The Grails Framework is using GitHub for it's sources (like GitBucket), but it's using BinTray for the plug-ins https://bintray.com/grails/plugins or other binary artifacts: https://bintray.com/grails

BinTray seems to better suited for distributions, plug-ins, metadata and this sort of stuff, and seems to have a very good integration with GitHub too.

Maybe GitBucket could try a similar approach?

McFoggy commented 8 years ago

@aadrian currenty the gitbucket plugin community is just a simple html page aggregating the availability of plugins for gitbucket ; it is not part of gitbucket itself. Of course a better support of plugins inside the gitbucket application would be far more valuable.