Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Curtis Rueden
    @ctrueden
    In general, there is a dichotomy/conflict between compile time—when you want to ensure building works against the oldest compatible/required version—and runtime—when you want to test again the newest compatible/available version.
    I would caution against doing "staged" releases of things locally, or anything like that.
    Just test against a big ol' bag of SNAPSHOTs—that's what they are for.
    Tobias Pietzsch
    @tpietzsch
    @ctrueden I know that you made meting-pot but I never used it
    Curtis Rueden
    @ctrueden
    Yeah, I haven't used it a lot either. There are integrations tests with cram in the repo, so I know it works (at least ostensibly).
    We planned to set up a Jenkins job to do it for all of ImageJ2 core, and all of Fiji.
    But I never got around to it.
    But it sounds like exactly what you need, given your comments above.
    The only other thing we are missing is a way to cut multiple releases at the same time. There are lots of edge cases with that though, which make it harder to automate well.
    Tobias Pietzsch
    @tpietzsch
    reading through the doc now
    Curtis Rueden
    @ctrueden
    See also the cram tests for examples.
    Happy to beef up the docs if things are opaque.
    I'd also be happy to create a Jenkins job that regularly tests whatever component(s) you want, however you want, within the powers of that script.
    Tobias Pietzsch
    @tpietzsch
    if no, then it would be great if you could add an example command line to run melting-pot for the scenario you describe (with the foo and bar dependencies)
    Curtis Rueden
    @ctrueden
    The cram tests link I mentioned above has example command line invocations.
    But yes, we should add it to the help blurb.
    I guess I need a man page. ;-)
    Tobias Pietzsch
    @tpietzsch
    @ctrueden thanks again for the help
    I now successfully released
    <dependency>
      <groupId>sc.fiji</groupId>
      <artifactId>bigdataviewer-vistools</artifactId>
      <version>1.0.0-beta-1</version>
    </dependency>
    Curtis Rueden
    @ctrueden
    I saw that! Didn't check it out yet though.
    Tobias Pietzsch
    @tpietzsch
    I even managed to set up the github / jenkins release-version stuff
    Curtis Rueden
    @ctrueden
    Cool.
    Tobias Pietzsch
    @tpietzsch
    proud of myself :-)
    Curtis Rueden
    @ctrueden
    High five! :hand:
    Tobias Pietzsch
    @tpietzsch
    :-D
    I didn't know about https://bitheap.org/cram/ until you mentioned it and I'm not really getting it yet...
    So a minimal melting-pot commandline in the help blurb would be really useful
    Hadrien Mary
    @hadim
    Hi guys. @ctrueden do you think https://github.com/hadim/KymographBuilder could be an official Fiji plugin at some point ?
    Or do I have to create a personal update site ?
    Curtis Rueden
    @ctrueden
    @hadim That project looks very well organized.
    It can be an official Fiji plugin if you meet the requirements at http://imagej.net/Fiji/Contribution_requirements
    Hadrien Mary
    @hadim
    Thanks
    Curtis Rueden
    @ctrueden
    It's really up to you, if you want to cede some creative control, or if you want full control.
    Hadrien Mary
    @hadim
    it does indeed
    Well I want to make it easly accessible so an "official" plugin is better in my opinion
    Curtis Rueden
    @ctrueden
    So then you have two choices: "standard" or "external"
    "external" gives you more control, whereas "standard" makes less work for you.
    Hadrien Mary
    @hadim
    and I don't think I'll loose control on it or if I do that will be for the best I guess
    hum what is the difference for the end user ?
    does they have to enable update site ?
    for external
    Curtis Rueden
    @ctrueden
    Well, by "cede control" I mean: someone else might cut a release of your plugin. Your master branch should be release ready all the time. Etc.
    Standard and external are both explained at the link above.
    Hadrien Mary
    @hadim
    Ok then a standard plugin is ok for me
    Curtis Rueden
    @ctrueden
    If standard, it lives at https://github.com/fiji and has sc.fiji groupId. The maintainers can push commits, cut releases, etc.
    If external, you keep in your org. Different groupId. No one but you (unless you desire otherwise) can push commits etc. Fiji maintainers need to file PRs.
    The downside is that if we need to make a change to bring your plugin up to compatible again with the latest stuff, then there might be a delay on you merging it, leaving users with a broken version of your plugin for days or weeks.
    Does that make sense?
    Hadrien Mary
    @hadim
    Yes perfectly