I’ve set aside a couple of days this week to work on a problem that I understand to be a concern for a number of authors, namely that there are various very useful Inform extensions that have never been updated to be compatible with 6L38.
I’ve already made updates to the following, so that they either already have been or soon will be submitted to the Inform Public Library (the repository that holds 6L38-compatible extensions and allows them to be installed and managed directly within the IDE, though you can also browse it less attractively online):
Simple Graphical Window
Title Screen
Scheduled Activities
Consolidated Multiple Actions (being beta-tested before submission, as it’s complex)
Hypothetical Questions (also being beta-tested)
I’ve also done some minor tweaks to Postures and Approaches, both of which had been updated but were presenting difficulties for some users.
It’s hardly practical to try to address all extensions that aren’t yet converted, but if people have particular requests that are serious stumbling blocks for them, then please let me know and I’ll try to fold these into my schedule. I’d like to direct my attention especially towards things that either a) someone is using and the need for that extension is preventing them from updating to the current Inform version or b) someone would really like to use in a current 6L38 project, but can’t. (As opposed to “I was browsing the extensions website and this old extension looked kind of interesting in theory even though I have no actual plans to run it at the moment and so far as I know neither does anyone else.”)
If it helps, the older extensions site is here. You may also like to look at a description of how to do basic updates for 6L02 (which usually also works for the current version 6L38) or forum thread explaining how extension filing works.
I should also add that we have volunteers working on a system for a more systematic storage of multiple extension versions, etc.
Emily Short's Interactive Storytelling 
Why not store the code in a version control system (like github.com) so you can tag releases by version number or spawn experimental branches people can test against. Not only that with github you can receive pull requests for fixes and features from others and then approve, comment, or deny as you see fit instead. Even if you didn’t use an online storage like github you would still benefit offering the source in a version controlled repository (like git) and be able to benefit from patches people send in. Just a thought.
Sukima’s idea sounds nice at first glance–I know that tinkering with extensions on my own helped me understand Inform a lot better & made me feel they were less set in stone. I felt less helpless.
I bet upcoming authors would be willing to deal with the annoying details the original author might not have time to. But it is tough to give away control of any piece of code.
I think such a repository would be a nice complement to Friends of I7 at https://github.com/i7/extensions though it may get sticky to have 2 places for the source.
github itself is a little overpowered for the average author, though, or at least for me. I needed an explanation for how to download extensions from github in a way that the IDE can understand them (you find the “Raw” button and right click to save the file), and I haven’t the faintest idea how pull requests work or where to find old versions. github seems like it’d need to be a backup to the relatively user-friendly Public Library/Extension page with download buttons and nicely displayed source code and documentation, rather than a replacement.
It’s not impossible or even particularly hard to build a site that would pull the extension files from Github, build their documentation, and make a nice catalog that is always in step with the git repository. With web hooks, it could even automagically update when the git repo did.
It would take someone some investment of development time and someone would have to host it, though.
As I said, there is someone — Dannii Willis — who has begun work on a system that will preserve back versions and allow people to call up the extensions matching the version they’re using; I don’t think it quite corresponds to any of these suggestions, but I also don’t know the technical details well enough to offer an outline. There’s a little discussion about it here, though this doesn’t go into vast technical detail.
In any case, this is not something that I’m directly involved in or can help with; all I can offer to do is a certain amount of extension updating.
As Emily said, I have begun working on a better system, but it will still be a while until it’s ready. (Never enough time!)
I intend to use Github as a backup, but want to make the uploading process considerably simpler than even the relatively simple Github online editor. Graham also wants the Public Library to be more curated than an open Github repo would be. My plan is to allow free uploads (like npm) but then have certain extensions be vetted to appear in the official Public Library page in the Inform 7 IDE. Ideally though it will be much faster to get updated extensions online than the fully manual email-the-maintainer process we have now.
I guess what I was getting at was not that the version control system be the medium of distribution but a means for allowing contributions from the outside. Any user of I7 can add any number of extensions it is not set in stone. As it stands a user downloads an extention, finds a bug, fixes it locally then email’s the author. Now the original source is out of date, the author has to manually parse the forked copy to figure out how to incorporate these changes. A VCS does all this for you. The beauty of a VCS based method of communication (like git) is that the original author still retains control of the project and can vet or deny contributions. A textual diff associated to a point in time is far more useful to manage then a copy of the source with goodness knows what changes and based on whatever code.
A package system like npm is great for the I7 GUI to provide suggestions and I’m all for that especially the curated list. But IIRC the original concept I was commenting on was the difficulty of the communication between a random contributor and the extension author using nothing more then email. And hence why having a history with the source would be valuable for such communication.
Emily, if possible, please update “Room Description Control” and “Single Paragraph Description”. I wanted to use them in a future project.
There are versions of these updated as far as 6L02 on the Public Library — if that’s not working for you, can you let me know what the problem is?