Continuing this conversation from another thread: Open Source! - #28 by matt_weiner
Yes, I’m curious as to how experimental or in-progress extensions are going to be dealt with. Will they remain in the I7 extensions repo on Github?
I’d love every extension to be in this new site, even the very experimental ones. The only real requirement is that they can be licensed under the CC Attribution license, so the rare GPL licensed extensions will have to be hosted elsewhere.
When uploading extensions it currently tells you that they need to meet the extension guidelines, but that is really only for those which are to be marked as Approved. (The idea is that if the site is loaded from within an IDE the search results would be limited to those which are approved.) The wording could be clarified to say that the guidelines are recommended for all but only required for approval.
The one new rule is that every extension must have a 0/000000 version number.
Suggestion: add an annotation to the extension format that indicates which versions it works on. Perhaps after the first three lines (title-author, description, credit), allow a line in the form
[= 6G60 6L02 =]which Inform will ignore, but which the extension site could use for categorizing? Just a list of all the versions it’s known to be compatible with.
Some requests for the new site:
- a list of all the extensions on the site, so we can easily tell which ones have been added and which ones haven’t
- the ability to browse the tags in alphabetical order
It looks really good! Thanks for putting it together.
I’d put the code up on github and let us have at it.
Is this it? github.com/i7/i7el
Cool. I’m going to have my web guy take a look at it and make suggestions. From my perspective, an express/nodejs website is perfectly fine. The PostgreSQL back end is fine too. I’m willing to pitch in to get this thing up and running as a production system. I’d prefer not to host it though, so we’d need a volunteer for that.
I see we’re talking about adding information to extensions as they are uploaded. (Adding a 0/000000-format version number, perhaps adding other metadata comments like I7 build compatibility.)
Just to lay out the options: this could be done with rule of “all information is embedded in the extension source” (so you’d have to modify the source to add this extra stuff). Or we could use a model of “upload the extension as-is, then add metadata in the i7el interface”. I don’t see either choice as obviously wrong or right – just gotta think about which we like.
I’m in favor of the “embedded” option, as it makes it easier to help people who have the wrong version of an extension (they can look into the source and see which version and compatibility it is, even if they lost the metadata).
If any of you would like to have editor access, just PM me your preferred Google account and I’ll add you.
The downside of embedding the I7 Release info in the extension is that you would have to update the extension in order to update the list. So an extension like Unicode Character Names by Graham Nelson would have to be updated each time a new I7 release comes out, even though it never actually needs to change. That means a new version number, the appearance of it being bumped on the front page, possibly people getting notified of updates. No, I’m pretty convinced that it’s better for that metadata to be external to the extension itself.
Is it possible to have tests associated with an extension and when a new release of I7 comes out, we could use a build process to test every extension and update the website accordingly? Just have green lights and red lights for compatibility reporting. I’m sure we can automate this, especially of the extensions are pushed to a github repository. We can have a Jenkins build server handle the details and the website can hook into the results.
I have a Jenkins server running on plover that I’d be happy to share.
One of my future plans was to make it update the Archive repo. We could then run tests from that. Getting the status back into the app on an extension by extension basis would be trickier, but possible I’m sure.
Every extension would need an umbrella story file to compile with and then run tests on. As long as each extension is in its own folder possibly with a package.config or build.config, we could do it. The build would compile every extension against all known I7 versions and report the results that the website can consume and display. Might take some work, but I feel this is completely doable.
Did anyone ever create a slack site for IF/I7 things? Not everyone is happy with the mud and I guess working through the issues in real-time might be better served on Slack.
Even if we could have automated tests, I’d still prefer author verified compatibilities to be displayed. There may be subtle changes in an I7 release which don’t show up as a compile error. Or the site saying it’s compatible with old releases may imply that authors are willing to support those old releases when they’re not (because setting up parallel I7 installs can be difficult etc.)
I7 releases are so infrequent I think our efforts would be better spent improving the site. Automated testing would be nice to have eventually, but manually testing <200 extensions every 18-24 months is not a large burden. 
Do we need authors to own their extensions or just be the original author?
The idea is each extension will have a list of maintainers, starting with the original uploader. They can add more maintainers, and you’ll also be able to ask to become a maintainer, to be approved by the librarian (ie Mark Musante).
Each extension can add links for a website, place of discussion, and place to report bugs. It doesn’t directly indicate who support requests should go to in the case of the maintainer not being the original author, but hopefully those links will be clear enough.
Would a solution be to not update classic extensions, but perhaps just tag the file on the site with the new version it’s compatible with? That way a user can just filter extensions by the version they’re using.
Yep, that’s how the site works now.
The IDE would go a URL with the release number: i7el.herokuapp.com/?pl=6M62
The site will filter extensions to only the approved ones, and also tell you if no version is available: i7el.herokuapp.com/extensions/fo … de?pl=6M62
Choosing an older release will show the latest version compatible with that release: i7el.herokuapp.com/extensions/gl … rt?pl=6L38
Looks very nice! I noticed my “Easy Doors” there is out of date, did you say that the newer IDE Library extensions are going to be incorporated en-masse, or should I do something to update it?