[tahoe-dev] suggestions for the next release

[Brian]

While going through the mechanics of today's 1.10 release, I came up
with a list of things I'd like to change for the next one. What do you
think?

* use "1.11" instead of "1.11.0" for the initial release

* rewrite "relnotes.txt": it's almost entirely boilerplate, and (being
   in the source tree) cannot contain strong identifiers like hashes of
   the release tarballs or the git revision id. What I've done for other
   projects is: one paragraph of download pointers to the new release,
   one paragraph summarizing what is new or fixed, and one paragraph
   explaining what the project does (the last paragraph remains the same
   between releases). Maybe just check in a template, instead of the
   final text.

* change the tarball name from "allmydata-tahoe-1.10.zip" to
   "tahoe-lafs-1.10.zip" or maybe "tahoelafs-1.10.zip" or
   "TahoeLafs-1.10.zip". The #1950 "allmydata"-ectomy would be a
   dependency. I'd like the name to be shorter, and to have fewer
   hyphens. It's too hard to type right now.

* The download URL is too long. The current release lives at:
 
https://tahoe-lafs.org/source/tahoe-lafs/releases/allmydata-tahoe-1.10.0.zip
   which doesn't even fit into a single 72-column wrapped email line. We
   already have "tahoe-lafs" in the DNS name, we don't need to repeat it.
   I suggest https://tahoe-lafs.org/downloads/tahoe-lafs-1.10.zip . I
   suggest having a "snapshots" or "tarballs" subdirectory of
   "downloads/" for the nightly/buildbot ones. And maybe an "old/"
   subdirectory for releases older than the last year.

* I think we should stop producing multiple tarball variations
   (gz/bz2/zip) and pick just one. Maybe whatever Twisted does.

* Put actual download links all over the site. Emphasize the download
   rather than quickstart.rst . My argument is that getting a potential
   user to download something represents committment: they've already
   stopped to look, and done the "hard" part of getting a tarball, now
   they're more likely to spend a few more minutes opening up the tarball
   and looking for a README or an INSTALL file. My problem with pointing
   everyone at quickstart.rst is that it takes several pages of reading
   before you can even find a download link. The previous several release
   emails (being just the contents of relnotes.txt) didn't have a
   download link, just a pointer to quickstart.rst (which becomes
   obsolete after any changes have been made, unless we make the URL even
   uglier and point it at a versioned copy of the file). Again, my
   inclination is to follow the pattern that Twisted has established.

* in the longer run, I'd like to produce single-file executables for
   non-developer users on major platforms (we might be able to get away
   with OS-X/windows/linux), then remove any confusing intrusive config
   assistance from the source tree. Basically make the source tree for
   developers who are willing to install some dependencies (maybe provide
   some pip/virtualenv support to help), have python-dev installed, have
   a C compiler, etc.

thoughts?
  -Brian