gitbucket / gitbucket-pages-plugin

Other
41 stars 10 forks source link

Semantic versioning to bundle plugin #19

Closed takezoe closed 7 years ago

takezoe commented 7 years ago

GitBucket 4.15 supports bundling plugins. It makes possible to include plugins in the gitbucket distribution and users can enable or disable them in the admin console.

I want to bundle plugins which are developed in the gitbucket organization, but it requires semantic versioning to manage bundled plugins. Is it possible to change version numbering and jar file naming as same as gist or other plugins?

yaroot commented 7 years ago

Okay will do. Does it make more sense to keep the major and minor version of this plugin the same as gitbucket?

aadrian commented 7 years ago

@yaroot IMHO it does make sense only for the plug-ins that are distributed with the core.

takezoe commented 7 years ago

@yaroot No, version number must be x.x.x but it's not related with gitbucket version as adrian explained. In addition, bundled plugins must be built with the next version of gitbucket before release. Now I'm considering how to make it.

yaroot commented 7 years ago

@takezoe yes I understand, but it would be nice if all the bundled plugins are the same version.

I'll change to semver without following the core version number.

aadrian commented 7 years ago

but it would be nice if all the bundled plugins are the same version.

Indeed. But that would really help only if all plug-ins would respect this convention :) .

takezoe commented 7 years ago

Do you mean if GitBucket version is 4.15.0, all plugins should be 4.15.0?

aadrian commented 7 years ago

@takezoe yes

takezoe commented 7 years ago

@yaroot Hm, if GitBucket core keeps binary compatibility, no need to update plugins. Do you think we should update plugins version along with GitBucket release even in such situation?

aadrian commented 7 years ago

@takezoe

if GitBucket core keeps binary compatibility, no need to update plugins.

but since the "distributed plug-ins" are packed together, they would be built along, every time GitBucket is built.

Do you think we should update plugins version along with GitBucket release even in such situation?

IMHO it would be simpler to just use the GitBucket version property as the version property for the distributed plug-ins too: this way no need to manage them separately.

takezoe commented 7 years ago

I would like to separate the build of bundle plugins from GitBucket core. We can update these plugins individually if it's necessary and users can install them by hand before the next GitBucket release. Such independency is advantage of separating plugins.

aadrian commented 7 years ago

I would like to separate the build of bundle plugins from GitBucket core.

I understand.

takezoe commented 7 years ago

@yaroot Thanks for a new release!

Is it possible to tag as same as version? Currently, a url of a released file is: https://github.com/gitbucket/gitbucket-pages-plugin/releases/download/v1.5.0/gitbucket-pages-plugin_2.12-1.5.0.jar

But build script expect v1.5.0 -> 1.5.0: https://github.com/gitbucket/gitbucket-pages-plugin/releases/download/1.5.0/gitbucket-pages-plugin_2.12-1.5.0.jar

aadrian commented 7 years ago

@takezoe @yaroot wouldn't be much better if plug-ins would be published (not just uploaded to the "release" page? as of Maven artifacts?

This way they could be addressed directly by all build tools using the Maven coordinates, and it would be also easier to check for new versions, not to mention about snapshots.

takezoe commented 7 years ago

Publishing to the Maven Central might be a good idea.

aadrian commented 7 years ago

Publishing to the Maven Central might be a good idea.

I know that publishing to Maven Central requires more work, but there seems to be easier alternatives nowadays, e.g. JFrog https://www.jfrog.com/knowledge-base/why-should-i-use-jcenter-over-maven-central/

If one of the official plug-ins would show/describe how to do it, than it would be easier for plug-in authors to do this as-well (or it could be even a requirement, like using semver, providing a description, etc).

yaroot commented 7 years ago

It's not much easier, but if you want a repo that's not synced to maven central then bintray is a good choice (example: sbt plugin repo). I have some projects that use bintray as a proxy to maven central.

takezoe commented 7 years ago

@yaroot Anyway, retagging is enough in this situation. or I will take an another solution to download jar files if you want to keep a current tag.

takezoe commented 7 years ago

@yaroot After all, I fixed the build script of GitBucket for the pages plugin: https://github.com/gitbucket/gitbucket/commit/0e498d1a81d3934c63266db79b1ec1540076f51b

So I close this issue. Thank you for your cooperation!