Pin to script-editor version 0.5.9 #5
Conversation
|
Thanks @imagejan, that's how I was compiling the jython-autocompletions jar locally with mvn. But with the script editor released, why should this pinning be necessary? |
|
@acardona you have to tell your project somehow that you want to use a newer version than defined in |
|
Thanks @frauzufall, that helped. But now: ... so now I have to create a fork, redirect my local git, push to it, do a pull request ... The amount of time that goes into non-constructive activities is really something. In any case, now it's clear: there is a master list of packages for scijava, and one has to update them there. No magic after all (i.e. no picking up the latest package, which I was naively expecting, unless a specific version is specified). |
|
@acardona for just updating |
|
@acardona you don't have to update all versions immediately in the "master list". Doing it as in this PR is completely ok. You can first release all the components you want to release and in the end update the There should be no magic involved, just using the newest version of everything would defeat the purpose of having |
It's the opposite: using everything the latest is the only way to ensure your software runs on the most feature-rich and hopefully most error-free version of the dependency libraries. Specifying--pinning--a version number for a library is instead a workaround for a mismatch in the API, to overcome breaking changes or to freeze a particular behavior, which is useful for e.g. creating a branch in a repository that is associated with the analysis done in a particular publication. The downside is that, eventually, that pinning is forgotten and becomes a surprise. Pinning each dependency at the current version ought to be a featured shell script of the scijava-scripts repository, if it isn't already; it's also the best argument ever for using pom.xml instead of plain javac + jar to package software. |
Strongly disagree. Releasing a new version of a specific library should be possible without having to ensure it works with all latest versions of all dependencies in |
|
You guys are thinking about reproducibility from the developer end, which is backwards. For reproducibility, Fiji is missing a menu item, for users, named "Freeze version" that emits a pom.xml with all the versions of all the jars installed, and enables recreating a full Fiji installation with it. |
|
Please don't tell me what I think about. I gave up trying to become a Fiji maintainer, so this feature is a story for someone else and not related to pinning versions here. In general, I aim for reproducibility on both user and developer side, they don't contradict each other. |
|
@acardona wrote:
For absolute reproducibility from the user perspective, Fiji always had Plugins > Utilities > Make Fiji Package which make a zip file containing an exact copy of your installation. This is however not very satisfying, as it duplicates the entire Fiji. Having a Bill Of Materials defining the exact version of each component is a way to achieve reproducibility in a simpler way. Albert, I don't know what you mean exactly by "user" and "developer" perspective. For users, it would be perfect if they can write in a publication: "We used Fiji 2.1.0", and everyone could just reproduce this by downloading Fiji 2.1.0, or running |
|
@imagejan I think the issue with that, in reality, is that the update sites are a distribution system which is not synced with Maven at all. The users or tool distributors are using update sites, and this messes with any system purely based on Maven. |
|
I am closing this, as this project will soon require script-editor version 0.5.10. There are two things I need from any of you (@imagejan , @frauzufall , @acardona ):
Currently, this project is pinned to a SNAPSHOT version of the editor and Travis build is failing. Once script-editor 0.5.10 is released, I will release here too, and upload both jars the the Java 8 update site . |
See #4.