Update frequency

[PeterT]

If you don't want the notification, maybe just change the preference value in "Preferences | Interface | Behavior"; deselect the "Show notification when new version is available" option.

[BetterRed]

I have a few programs that notify of updates similar to calibre. The choices they offer include -

Look at the change log,
Install the update,
Download the update,
Remind me later,
Skip this update.

On one of them I often use the last one.

In calibre I find the message in the status line more of an irritation than the weekly popup message.

BR

[eschwartz]

I run from source so it is really easy to perform incremental updates.

cd ~/git/calibre && git pull

It sometimes takes a whole minute, which is annoying.

[BetterRed]

Originally Posted by eschwartz

I run from source so it is really easy to perform incremental updates.

cd ~/git/calibre && git pull

It sometimes takes a whole minute, which is annoying.

Who's a clever boy then

BR

[Sabardeyn]

I hear you. Too many computer issues not to keep old versions and/or extra copies around. Right now, readily at hand, I only have the last 33 versions available.

[eschwartz]

Originally Posted by kovidgoyal

I'm allowed to do pretty much anything I want. The question, is as, always to weigh the benefits vs the costs of doing something.

I don't know how much benefit there is, but there is very little cost in

mktorrent --web-seed=http://download.calibre-ebook.com/${calibre-version},http://sourceforge.net/projects/calibre/files/1.46.0/  --announce="" /path/to/release

and posting that on the download pages?

And it would be faster to download.

[eschwartz]

Originally Posted by BetterRed

Who's a clever boy then

BR

I do tricks, too.

Just pointing another in the multitude of options.

[BetterRed]

Originally Posted by eschwartz

I don't know how much benefit there is, but there is very little cost in

mktorrent --web-seed=http://download.calibre-ebook.com/${calibre-version} --announce="" /path/to/release

and posting that on the download pages?

And it would be faster to download.

I would think there'd be very little benefit in providing a torrent links for anything but the current version. If someone really needs an earlier version then they can do a file download.

Maybe do a trial on the Windows versions for a few months to see if it has any impact on download traffic. Be interesting to know what proportion of LO downloads are via torrent, they've had it for some time now.

BR

[kovidgoyal]

Originally Posted by eschwartz

I don't know how much benefit there is, but there is very little cost

What happens to an existing swarm when I do a re-release because of a bug? I dont know of any way to handle that in torrent, except by bumping the version number and filename, which would actually lead to more update notifications, which was why this whole thread started in the first place.

With HTTP downloads, any in-progress downloads complete nicely in case of a re-release thanks to the way files work in linux.

The only way to handle that, that I can see would be to change the update notification code in calibre to not notify about x.y.z version bumps.

Then there is the inevitable feature requests I will get from linux users, asking for a way to use the torrents in the linux installer.

Then there is the fact that torrent downloading breaks download counts, something I like to track. I dont see anyway around that short of setting up a proper torrent seed server as opposed to using web seeding. More costs.

These things are never quite as simple as they appear at first glance.

[eschwartz]

I suppose that is true.

(I wouldn't mind (selfishly) x.y.z values anyways, to work with re-releases. Even if the builtin notifier ignored it, my script could manually trigger an update.

[BetterRed]

Originally Posted by kovidgoyal

What happens to an existing swarm when I do a re-release because of a bug? I dont know of any way to handle that in torrent, except by bumping the version number and filename, which would actually lead to more update notifications, which was why this whole thread started in the first place.

With HTTP downloads, any in-progress downloads complete nicely in case of a re-release thanks to the way files work in linux.

The only way to handle that, that I can see would be to change the update notification code in calibre to not notify about x.y.z version bumps.

Then there is the inevitable feature requests I will get from linux users, asking for a way to use the torrents in the linux installer.

Then there is the fact that torrent downloading breaks download counts, something I like to track. I dont see anyway around that short of setting up a proper torrent seed server as opposed to using web seeding. More costs.

These things are never quite as simple as they appear at first glance.

IMO fix-up releases should get a x.y.z bump anyway with a notify in calibre. They are infrequent, and I can only recall one instance when there was more than one.

Suggest you'd name the torrent files the same as the current download file with the addition of .torrent eg calibre-64bit-1.47.0.msi.torrent.

When you pushed a new release, users would get the same notify, then torrent.freaks would download the new .torrent file, and others would download the new .msi file. So a download of blah.msi.torrent would increment the same counters as a download of blah.msi.

I would suggest start with .torrents for the 3 Windows flavours (which is 85% of the installed base) as a 'trial'. And only think about linux and os/x if the trial reduces the download traffic by an appreciable amount.

With respect to automated installs, any torrent client worth its salt can run a script when a torrent finishes.

BR

[DoctorOhh]

Originally Posted by taosaur

I was considering bandwidth before and figured that maybe getting the donate button in front of people offset the costs of having the app downloaded and re-downloaded more often than necessary.

Since I didn't recall a donate button, your obsessing over it required me to go look at the page again. I had to scroll down to bring it into view on my browser.

Originally Posted by taosaur

and reduce frustration for casual users who want to stay up to date, but don't want update prompts interrupting our workflow nearly every time we open the program.

The casual user that doesn't like the prompt would simply turn it off and never see it pop up again.

[theducks]

+1 on on using the 'z' digit JUST for emergency version fixes for ALL releases. If it is bad enough for a emergency patchup... those that have downloaded need to get some sort of notice (besides MR)

Since Calibre release Version 1, this digit has been 0, so why not?


If the upgrade is for currently version (matches x and y), Make the notice Red or blink to inform them of a emergency patch. The notice stays normal for older installed versions

[kovidgoyal]

@theducks: Re-releases are not emergency patches, they are patches for minor bugs that are in less used parts of calibre that most people would not notice and are therefore not worth sending everyone a new update notice for. They are never bugs that could cause severe consequences, such as data loss. Those, if discovered always get their own new version.

[taosaur]

Originally Posted by DoctorOhh

The casual user that doesn't like the prompt would simply turn it off and never see it pop up again.

It's not about not liking the prompt; it's about the frequency and prominence of the prompt skewing the user experience. People want to keep their software up to date, and if the program is telling them to update they feel like they should update. Most people's experience of updates is security-oriented: Java updates, Windows updates, anit-virus updates, and etc. It's not the case with Calibre, but the psychology is still there. We want to see the prompt, we just don't want it to be the first thing we see every time we open the program.

Implementing "recommended updates only" would improve the user experience and save Kovid bandwidth, and doesn't seem like it would take a lot of code (though I could be wrong there).