search

Wikidata / Wikidata-Toolkit

Java library to interact with Wikibase
https://www.mediawiki.org/wiki/Wikidata_Toolkit
Apache License 2.0
375 stars 100 forks source link

Find some way to quickly respond in maven to breaking changes in export format #108

Open shilad opened 9 years ago

shilad commented 9 years ago

I suspect that many of Wikidata Toolkit's customers are (like me) maven users. When a breaking change happens in Wikidata's export format (which seems to occur regularly), it would be excellent if there is some way for me to quickly access a new maven release that adapts to the change.

Two ideas for this are:

Right now, there's no good way for me to make my downstream library work during release gaps in Wikidata Toolkit without releasing a custom version of Wikidata-Toolkit to maven (yuck!)

fer-rum commented 9 years ago

@mkroetzsch I assigned this to you, since you are the one that knows best how to manage the maven releases. No hurry though.

@shilad You are right, there are quite some breaking changes at the moment. Hopefully the situation becomes more stable in the future. We try our best to keep up, but are all a bit tied down at the moment. This said, thanks for your commit, we really appreciate it.

shilad commented 9 years ago

@mkroetzsch @fer-rum I ended up publishing my own forked maven repos (e.g. http://search.maven.org/#artifactdetails%7Corg.wikibrainapi%7Cwdtk-distribution%7C0.3.3.shilad%7Cpom), so I'm fine for the moment.

My pull request is now invalid because the pom metadata is based on my fork, not the original :(

Hronom commented 9 years ago

We are use maven and start use this tool, but several months have passed since this tool not work, because of very slow release to maven central.

Please do something with this...

mkroetzsch commented 9 years ago

I would like to re-check what this issue report is actually asking for. Having more frequent releases to react quickly to breaking changes is a noble goal. But what kind of outcome are we looking for here? Some general things are getting better as the project is becoming more mature, and the same holds for Wikidata (we should hope for fewer breaking changes in the future). That's great, but it will never eliminate the problem of breaking changes completely.

If somebody wanted to make more frequent releases, what would be needed? Maybe not so much. In general, we strive to keep master working at all times (that is, not to break it my merging unfinished code; it might of course also stop working due to changes in Wikidata). Therefore, for most means and purposes, master could be considered the "stable release branch" that @shilad suggested, but this has always been the case. Of course, there can be breaking changes in master -- we are still in 0.x.x for a reason -- but this is also true for all releases we make now.

So one could already release regular SNAPSHOTs of master now. If somebody wants to set up an automated generation of snapshot builds (once a week should suffice), then this has my full support. In general, an important long-term step towards really solving this issue would be to engage additional contributors who can help with release management (and with developing fixes for breaking changes in the first place).

shilad commented 9 years ago

Markus,

My original question was indeed specifically about maven releases, and I do think an automated mvn SNAPSHOT release against master would solve the issue. I ended up releasing my own Wikidata artifacts as a one-time fix, and this seemed to work fine for me.

-Shilad

On Sat, Sep 5, 2015 at 4:08 PM, Markus Krötzsch notifications@github.com wrote:

I would like to re-check what this issue report is actually asking for. Having more frequent releases to react quickly to breaking changes is a noble goal. But what kind of outcome are we looking for here? Some general things are getting better as the project is becoming more mature, and the same holds for Wikidata (we should hope for fewer breaking changes in the future). That's great, but it will never eliminate the problem of breaking changes completely.

If somebody wanted to make more frequent releases, what would be needed? Maybe not so much. In general, we strive to keep master working at all times (that is, not to break it my merging unfinished code; it might of course also stop working due to changes in Wikidata). Therefore, for most means and purposes, master could be considered the "stable release branch" that @shilad https://github.com/shilad suggested, but this has always been the case. Of course, there can be breaking changes in master -- we are still in 0.x.x for a reason -- but this is also true for all releases we make now.

So one could already release regular SNAPSHOTs of master now. If somebody wants to set up an automated generation of snapshot builds (once a week should suffice), then this has my full support. In general, an important long-term step towards really solving this issue would be to engage additional contributors who can help with release management (and with developing fixes for breaking changes in the first place).

— Reply to this email directly or view it on GitHub https://github.com/Wikidata/Wikidata-Toolkit/issues/108#issuecomment-137994695 .

robertvazan commented 3 years ago

I would be also in favor of creating bugfix release from master whenever someone requests it.

Ideally, release would just involve running a script. On my projects, I am using a GitHub workflow that does most of the work. Secrets (MAVEN_* variables) can be configured in GitHub settings. A small script however still has to run on my workstation to:

Unfortunately, I cannot share this client-side script, because it's too tied into my other scripts, but it wouldn't be hard to recreate. Some things might have to be done differently in multi-module project.