Login  Register

Re: ImageJ release cycle

Posted by dscho on Jun 04, 2013; 5:49pm
URL: http://imagej.273.s1.nabble.com/ImageJ-release-cycle-tp5003165p5003215.html

Dear Wayne,

sorry, I did not have time yesterday to play more with the continuous
releases.

On Sun, 2 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote:

> On Jun 1, 2013, at 6:17 PM, Johannes Schindelin wrote:
>
> > I got that far by inspecting the extracted .iss files. What I missed
> > (which innounp is apparently not able to detect) is the 'users-modify'
> > permission on the directory.
> >
> > So here is the result of my work so far:
> >
> > http://jenkins.imagej.net/job/ImageJ1-releases/label=Windows/
> > and
> > http://jenkins.imagej.net/job/ImageJ1-releases/label=master/
>
> The releases for Windows and Linux look good! I tested them and found
> only one problem. The "Enable single instance listener" option in
> Edit>Options>Misc is ignored on bother Windows and Linux. You get a new
> ImageJ instance each time you run the launcher.

That's too bad. I did not yet have time to look into this. Probably
renaming the launcher to 'debug' will yield some helpful output, right?

> I have one question. How do I update the files in the plugins, macros
> and luts directories on your Jenkins server?

As I mentioned in my mail yesterday morning, it is all maintained in a Git
repository:

        https://github.com/imagej/ij1-installer/

The plugins, macros and LUTs all live in the app/ directory and are copied
verbatim to any of the archives/installers (this should also make them
more consistent between the different operating systems and
architectures).

Of course I added you to the team of that repository, so you can make all
the changes you want! Jenkins will pick them up the next time it builds a
release.

> > Note: MacOSX needs work, I concentrated on Linux and Windows (which
> > should be fine).

Note: MacOSX is the only platform which does not use the ImageJ launcher
yet. I would really like to change that: the difference between ImageJ.app
and ImageJ64.app is unnecessary, the ImageJ launcher can solve that
problem (by having two launchers, always starting with the 32-bit one and
handing off to the 64-bit one whenever appropriate).

Do you have objections?

> > The job is configured to take http://imagej.net/ij/ij.jar, extract its
> > version, and make all of the installers/archives at 11pm CDT every
> > night.
>
> It would be better if they were only updated for final releases (e.g.
> 1.47r) and not for daily builds (e.g. 1.47r21).

I hope you do not feel too strongly about it because that would actually
be additional work. For the moment, Jenkins monitors the timestamp of the
URL http://imagej.net/ij.jar and builds new releases whenever the
timestamp changes. I also worked quite a bit on making the version more
visible (see
https://github.com/imagej/ij1-installer/blob/master/add-jenkins-badge.groovy)
in the build list. It worked beautifully:

        http://jenkins.imagej.net/job/ImageJ1-releases/

(builds up until #14 can be safely ignored, they are leftovers from some
previous experiments).

So if you do not mind, I would really like to build also releases for
"nightly" versions, just because it is easier for me that way.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html