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?
Does being on the list of maintainers for a given extension just mean you are allowed to make updates and changes, or that you are in charge of making updates? Is it possible to remove oneself from “maintainer” status for a given extension if you uploaded it but it’s not yours?
Another question: I’m not always sure how to apply the tags, e.g. what sorts of extensions count as “adaptive prose,” which ones count as “input,” and so on. Would it make sense to attach descriptions to some of the more ambiguous tags? (Although I have a similar confusion with some of the categories in the existing public library, so maybe it’s just me.)
HanonO, I do want all the extensions updated, if you’d like to help that would be great
bg, the list of maintainers would just be all the people who can update the extension. As an editor you can already do that for every extension already
On tags, just use what you think is best. It would be possible to add descriptions in the future, but I think most of them are self explanatory. If you think they’re ambiguous feel free to change them if you can think of less ambiguous synonyms.
Ok, thanks.
Another question: what should we do about existing extensions that don’t have a date in the version number? There are at least two or three in the public library that don’t. Should we contact the extension authors and ask them to add dates? That might not make sense, though, for old extensions that are no longer in use. Should we just put in a bunch of zeroes?
When I added the built in extensions from 6G60, 6L02 and 6L38 I used the date I7 was released for the unversioned extensions. I’d do the same for other 6M62, and if you can find a date for anything in the PL great, otherwise just pick today’s date.
Requiring full version numbers is a change from how we’ve done extensions in the past, but it will make extension updates so much easier going forwards.
Ok, yeah, I forgot that on the PL site there’s a “last modified” date.
Thanks!