Le 31 mars 05, à 13:08, M. Uli Kusterer a écrit :
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>
Well, you make good points, yes. Still I'm not speaking of automatic
update without the user's consent
-- it should be volunteer.
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.
My idea was more, "grab a file showing the updates from the cvs". The
"real" ChangeLog isn't the right file for that job -- too technical
indeed.
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.
Hmm.... you're probably right. Though, I still think we should have a
"CVS/SVN" install available for those who wants. But a same update
mechanism using .tgz is also needed, yes, and probably will be much
more used by the normal user.
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.
Well, I think we definitely wants a binary update mechanism, for the
reasons you describe. But I still think a CVS/SVN installer would also
be quite handy.. it's not because a cvs checkout isn't that difficult
that having a good UI for dealing with it is bad :-)
But you're right, it's likely that casual users won't want that; this
kind of update mechanism is ok for devs and power users, probably not
my grandmother.
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
