Go ahead. I’m still working on rdc-improvements on my local machine believe it or not, so it’s not really out of date, but you don’t need to have it in the github repo if you don’t want to. I’m still a bit uncomfortable updating Emily Short’s extension (a) without her explicit permission and (b) without renaming it and moving it over to my directory. But it was still on my to-do list when I dropped Inform to wait for it to be open-sourced, and is probably the next thing I’ll get back to after these v10 updates.
1 Like
Hi!
Sorry about those - they were minor tweaks, I don’t know why I left those getting stale so long ago. I’ve deleted both my branches on github (and FWIW I have it locally), good job cleaning things up!
// Peter
2 Likes
The Extensions github pages have been updated (along with informant, the script that generates them which is now a little messy and needs cleanup, and also its README needs updating… sigh.)
But there’s actually a place you can go and see lists of working extensions for 6M62 and 10.1, with descriptions.
The question is: have we made it too easy? Is the coming generation of I7 programmers going to grow up soft? Why back in my day, 14 months ago…
1 Like
The question is: have we made it too easy? Is the coming generation of I7 programmers going to grow up soft? Why back in my day, 14 months ago…
Snort. Having just spent two days debugging an incomprehensible failure in Undo Output Control (I got it working, but I still don’t know what caused the error); and currently trying to figure out how to push a patch upstream so that Compliant Characters doesn’t have to replace the entire parser to do its work; and dealing with recurrent crash/freeze/stale cache bugs in the IDE… I don’t think there’s any risk of that. Wish there was. 
@Zed , could you rerun the Smoketest? (I think it should run on the master branch on a regular basis; it would be a great advantage to extension developers.) I’d like to see if the stuff I committed will pass.
Please walk me through this. I’ve updated “Undo Output Control-v6.i7x” on the master branch. How do I get it pushed into the 10.1 branch?
For now, master is no longer a part of the expected workflow. The only things I, personally, expect to do with the master branch are to add comments to its extensions pointing people at the version-specific branches and to update informant or the github pages. Changes destined for 9.3 or 10.1 get made in those branches or sub-branches of those branches, and then one submits a pull request. People can commit things to master if for whatever reason they want to share them publicly without them being on a track to end up in the 9.3 or 10.1 branches.
This could change if we pursue the indicate-targeted-release-in-comments strategy. Automation would obviously be really nice, but it’s not happening this weekend.
Yeah, we need to document the process and expectations about the workflow (which hasn’t happened yet 'cause it’s been less than 48 hours since we picked a direction to go…)
There’s nothing special about the smoketester except making readable HTML results. If you use the appropriate branch of the Friends Repo as your External extensions dir and can compile a story file containing:
Include My Extension by Me.
Lab is a room.
successfully, you have as much info about its suitability as the smoketester provides.
You’re undervaluing your Smoketester. I really like being able to see which of the examples compiled. Doing that by hand is a PAIN IN THE…
This is the only way I stopped the typos and whitespace errors in the examples for several of my extensions. Without the Smoketest, I will go back to just having typos in the extensions. There is something special about it. If you sent me the code, I could just run it locally, I guess. Really, @zed, don’t undervalue it: copy-pasting each example and trying to compile each one by hand takes hours, while looking at the Smoketest results takes minutes.
So, what I did was to
(1) cherry-pick the appropriate change from ‘master’ (luckily, it was a single commit; otherwise I would have remade it as a diff)
(2) drop these changes into my local 10.1 branch and commit;
(3) push that back up to neroden/10.1 at github;
(4) log into github on the web and make the pull request;
(5) than approve the pull request merge (since it was non-conflicting and it’s my directory anyway).
This seems to work.
My plan is to keep my most bleeding-edge WIP versions in “master” when I want to share them, and my working versions in 10.1. So (after I finish all the 10.1 conversions) “master” will start out with the same stuff which is in 10.1, but then it will add new, possibly-full-of-breakage revised versions sometimes when 10.1 doesn’t.
Oh. Important point on version numbers.
Inform v10 converts 5/171116 to 5.171116. This was… probably not the right choice, but here we are. It means the first version number which is larger than this is 5.171117. (I would have converted it to 5.0.17116.)
So, I just caught this – this does not work, @zed. A bunch of the version numbers which @zed just added are going to compare as less than the older versions, because 3 is less than 220521. Whoops?
This is why I’ve been incrementing the major version number on all of my extensions, even though I like to have the date; I’ve been putting the date in the patchlevel instead. FWIW, all of mine are fixed.
This is relevant for something I’m debating: I just fixed Michael Martin’s “Reactable Quips” and as a result also fixed his “Quip-Based Conversation” (which doesn’t need any changes, it simply depends on the other one). But before moving them over to the 10.1 branch, I’m debating what I need to do with the version numbers.
facepalm. I’m not positive it’s worth fixing, though: I expect that in general, people will be using fresh external dirs with 10.1. Or maybe I have weirdly unrealistic ideas about how IDE users actually use Inform.
If there’s a consensus it should be fixed, I think incrementing the major version would be the way to go.
Edited to add: what do people think? should the versions be re-revised? (I’m leaning toward yes. sigh.)
I suggest incrementing the major version number. It’s what I would have done with the others from the start if my brain hadn’t gotten stuck on the idea that string-comparison ordering should have worked for the minor version…
1 Like
My instinct is to just increment all the major versions. (With the exceptions of the extensions which only had a major version and no date to start with, obviously.)
Yeah, I’m doing it. Currently running another smoketest to see if the version number changes break other things that may have been asking for a particular version.
Thanks. I only just implemented the example compiling for I7 v10 testing, and all my I7 time has been taken up by testing / bug reporting / Friends repo planning and it truly hadn’t even occurred to me yet that it’s a thing that would have practical value for development in I7.
1 Like
Dannii (rightly) pointed out that bumping the major version numbers flouts semantic version number practice, so the pull request is still pending while I try a hail mary play: I’ve submitted an improvement request asking that 1/220525 be treated as 1.1.220525. At this late date, I doubt it’s going to happen, but we’ll see.
But for now I withdraw my blanket recommendation to willy-nilly increment major version numbers.
Yeah, actually, that would be a great impovement. I would like to note that I’ve been making my numbers MAJOR.MINOR.DATE, so I’ll pile on with the request.
For extensions which actually continue to work under v10, it probably would be nice if we could keep the major version numbers the same.
For mine, I went ahead and bumped all the major version numbers because nearly all of them broke and required rewriting; so the API has changed from “use 6M62” to “use 10.1” and the major version numbers should change. The only exceptions were “Nathanael’s Cookbook”, which isn’t really an extension despite being formatted as one, so whatever I do doesn’t matter much (my plan is to update the major version number whenever I change the examples because the examples are the API), and “Verb Stripping”, which I think nobody is using.
I think in general every extension which has I6 replacement code, which has to change the syntax to the new replacing 'Name', has changed its API, becuase it now works under 10.1 and not under 6M62, so they all need new major versions.
However, for extensions which were pure I7 and kept working, we would want to keep the major version the same.
muppet flail!!! – Dr. Nelson agreed to count the date-part of old versions as patch level instead of minor version (with the minor version in that case being counted as 0).
So now the dozens of extensions in the 10.1 branch that previously had date-style versions would be picked first if one of them and its predecessor were both available.
They all started life with a minor version number of 2 or 3. Ideally it would have been 1… but reducing a version number of a published extension is a more serious class of programmer-crime than skipping some minor version numbers. I think we could get away with it during this pre-release window, given that the people in this thread are very likely the only people using the 10.1 branch, but I think it’s time to leave good enough alone. (And not just because I don’t want to do the work – this one would be easy.)
2 Likes
Awesome! I admit to being utterly puzzled as to how this code change actually does this.
Graphs::show_needs_r is pretty cryptic to me.
The documentation now needs to be updated in both inbuild and Writing With Inform. I left a comment at the bug report, but I’m not sure if I should also try to work up documentation patches (I haven’t actually found these pieces of documentation in the source code yet)
Still can’t find the version number description in the Inbuild docs, but I found it in Writing With Inform.txt and submitted a bug report and a patch. (I7-2131)
Wooo, a nice milestone: I’ve updated all of my extensions.
1 Like
So, when making an update to the extension that’s not major, how do you know whether to bump the middle number or the last number?
If you added or deprecated one or more features, up the minor version. If you just fixed bugs, up the patch level.
But note that even the smallest incompatible change must become a new major version. (Though not if you consider it to be a bug you’re fixing.) Minor versions can involve lots of code and major versions can be very small, what matters is whether you’re breaking backwards compatibility.
1 Like
As @Zed has already realized, the version number interpretation change hasn’t happened. I submitted a patch for it to bug I7-2130 ( Log in with Atlassian account ) however. It turns out inweb needs to be patched, and I submitted the patch for it.
I finally finished my work on improving Room Description Control by Emily Short, and the three associated extensions (on the rdc-improvements branch). In accordance with previous agreement from, oh, 2017 or so, that I could update these, I’m going ahead pushing these improvements to “master” – it’s all bugfixes, internal fixes for speed and compilation, and an added debugging feature. Technically there’s a new feature (“level 2 paragraph debugging”), so there’s one minor version bump.
But I’m waiting on pushing them to the 10.1 branch until the version number thing is worked out.