At 15:50 Uhr +0100 30.03.2005, Nicolas Roard wrote:
I was just thinking about software distribution... the fans of
web-applications have it right: when a bug is corrected, the user
see the correction immediately. No "releases" needed. Of course,
webapps have other problems (latency, no drag'n drop..). But the
idea of fixing something and automatically "push it" to the client
is a good one.
You're thinking like a developer. It may help to see this from the
point of view of the user, too. Some people don't update because
they're afraid it will introduce new bugs that will hinder their
ability to get work done even more. "never touch a working system"
and "the devil you know / the devil you don't".
That's the short version. For the long version, see my blog:
<http://www.zathras.de/angelweb/x2005-03-13.htm>
But what if we had some kind of file containing all the information
to grab a cvs ? We could just say to the users "download this file,
double-click on it". That will launch Installer.app.
Installer.app will then grab the ChangeLog, or just list the
available tags, and propose that to the user;
the user choose a version (a tag) or the bleeding edge, and click on
the "install" button. Installer.app grab the sources and launch the
compilation / installation.
ChangeLog isn't that interesting to most users. It's written from
the developers' point of view. As such, most statements reference
names of internal classes that users never get to see, or they use
inconsistent terminology because nobody reviews them for correct
terminology. It's a bad idea to show this to users, at least as a
default.
It's not very difficult to do in fact (it's just a shell over
cvs/svn), but it would provide a much smoother experience for
people, and will let us have an easy way of "pushing" new versions.
The installer could even check regularly the tags to warn the user
for any new releases.
Look at MacPAD for one possible update-check mechanism. And I think
going through CVS isn't a good idea. Tagging a release is cheap.
Actually packaging it up and offering it for download means some
additional time has gone by, it has been tested a little more and
it's more likely to be safe.
Of course we could continue issue tgz releases anyway, for people
that don't want to compile, but nowadays compilation is very fast,
so..
What do you think ?
Multiple points of failure, duplication of effort, waste of CPU
cycles. Remember, your users may have different versions of GCC
installed (some incompatible, like Apple's), or may have some other
problems on their machine. Those needn't be big problems, just subtle
differences that prevent the Makefile from running. You completely
eliminate a whole bunch of these problems if you just get them a
precompiled binary. Also, when a packager does this compile once, all
his clients don't need to run again, saving them CPU cycles that they
can use for other things.
There will always be people who want to compile themselves, but
those will mostly be the more advanced users, so they'll be able to
do without a CVS installer. I'd rather spend manpower on getting
regular installers out the door. Of course, I'm fine with having
installation scripts etc. No need to make life harder for the
packagers. But packagers should be savvy enough to do a CVS checkout.
They probably do that all day anyway.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
