[rabbitmq-discuss] Packaging

[Edwin Fine]

>
>
> > Does Windows really require a full-blown installer? It might be easier to
> > simply offer a zip and require installing the stock Erlang runtime
> package
> > separately, maybe with a hint to version compatibility or recommendation.
> > It's not *that* hard.
>
> Holger, you're preaching to the converted, especially being somebody
> who has never installed Rabbit themselves.
>
> But personally I've only run Rabbit on BSD, Arch and OSX, so I am not
> the right person to judge the ease of use from a Windows developer's
> perspective.
>
> I have received a few comments here and there that surround Windows
> installers.
>
> So if there is somebody who runs Rabbit on Windows who thinks an
> installer would be a good idea, may they step forward.
>

I'm not a fan of Windows installers, because they usually put things into
the registry. The uninstaller is supposed to remove these things, but too
often they just don't work, leaving you with dozens or even hundreds of
registry entries that you have to clean up somehow. Or, if you happen to
change the drive letter on which the software is installed (by moving the
software, for example), it breaks. Unless you use some third party tools.

One of the few times I would see a Windows installer as being useful in this
case, MAYBE, is if you want to install RabbitMQ as a Windows service to
start automatically when Windows starts, although how that plays with the
Erlang VM needing to be running first, I am not sure. Maybe there could be
some Windows code that starts the VM first. I'm sure there are better ways;
I hardly touch Windows these days except when I am forced to.

The bottom line is that a self-extracting .exe archive (rather than a zip,
which you could offer as well) with an expectation of a minimum running
version of Erlang, plus some good command (batch) scripts and installation
instructions would probably do the trick.

In terms of an earlier email about how to package the clients and server, I
see it like this: repackage (and optionally refactor) the server into
server-specific components and common components. Make the common components
a separate Erlang app; ditto for client and server, and have the server and
client depend on this app. Put in checks on both server and client side that
they are running with a suitable version of the common app, and fail with a
clear warning message if this is not the case. Make it easy for users to
know which version of the common app the client or server depend on,
preferably a simple script that invokes Erlang to delve into the guts and
bring out the answer.

Offer a number of packaging options: client, server, and common; client and
common; server and common; and common alone (for bug fixes and
improvements).

My 2c worth.

Ed


> Ben
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081108/f0c84b02/attachment.htm