Closed takezoe closed 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?
@yaroot IMHO it does make sense only for the plug-ins that are distributed with the core.
@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.
@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.
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 :) .
Do you mean if GitBucket version is 4.15.0
, all plugins should be 4.15.0
?
@takezoe yes
@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?
@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.
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.
I would like to separate the build of bundle plugins from GitBucket core.
I understand.
@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
@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.
Publishing to the Maven Central might be a good idea.
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).
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.
@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.
@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!
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?