Quote:
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