Future of the "development" branch on friends-of-i7

Authoring Inform 7
1

I’ve been using it for development with 10.2 (or indeed whatever the bleeding-edge version of Inform is at any given time).

The stated purpose is to allow people to develop for whatever version they like.

@Dannii said we should discuss the future of this branch.

Practically nobody else is using it at all. For anything. Not since the 10.1 branch was created. I checked the git log. There’s one update by David Wheeler in May 2022 (I think that was before the 10.1 branch), one update by Xavid in July of 2022, one by Brian Rushton in April 2023.

There’s a number of updates to older extensions (extensions written by many different people) by Zed Lopez. Other than that, it’s all me.

I took the liberty of updating some of the older extensions which I’ve been using in order to try to get a functioning environment without a lot of fiddling. I hope nobody minds.

It appears that most authors are updating the 10.1 (or 9.3) branches directly, and not ever trying to update the master branch, with the result that the master branch is falling behind the 10.1 branch. I’ve also been pulling improved versions from the 10.1 branch where they exist.

The “next version of Inform” (currently 10.2) is a moving target until it’s released. My thought was that, in the way development branches often work, the “master” branch could try to keep up with the moving target of the “fresh from Github” version of Inform, with the understanding that it would probably never be fully operational since that version of Inform may change at any time. When 10.2 is released, I would then expect a 10.2 branch to be made contaning the parts that are working.

But if people want to use the master branch for something else, let me know.

Footnote: if we want to change the name of the branch in order to avoid using the name “master” (for various reasons a lot of places have been moving away from the name “master”), “main” is the popular new default, but “development” is a more descriptive alternative. [Updated title of the thread since this change just happened]

4 Likes
2

Renaming to development would make sense with how the branch can be used now.

If there are differences between extensions for 10.1 and 10.2, then it’s time that we make a 10.2 branch.

Okay, both of those are now done.

My main concern was with you updating extensions for other people in master. I think it’s best to just leave that. It’s not essential to have up to date versions there.

3

What I’ve done with the inform6unix and some other packages is have a dev branch where all development is done. When a new release is made, not just an update, dev is merged to master and tagged. The old dev branch is deleted and a new one created. Incremental updates to the latest release are made in master. If you want to do incremental updates to earlier releases, branch off at that tag.

4

While that’s a decent strategy for many situations, it doesn’t really make sense for the extensions repo. It doesn’t have releases like that!

5

Concur with dannii (why those double letters ? I have mistyped twice…), indeed the inform6.41/punyinform situation is different from inform 10.

the best thing possible for friends of I7 (and 10) is that Lord Inform gives an advance final beta/release candidate in advance to the Friends (that is, the active extension/contrib libraries developers) prior of the next release, this will render feasible the inevitable fixing of incompatibilities in advance of the next Inform 10 release.

Best regards from Italy,
dott. Piergiorgio.

6

the best thing possible for friends of I7 (and 10) is that Lord Inform gives an advance final beta/release candidate in advance to the Friends (that is, the active extension/contrib libraries developers) prior of the next release

Now that it’s open source, we basically already have this, informally.

I said 10.2 here out of habit: I recently learned that the forthcoming version will be version 11. This hasn’t been announced publicly that I know of, but I did confirm with Graham that it’s not meant to be a surprise and I could say it publicly.

if we want to change the name of the branch in order to avoid using the name “master” (for various reasons a lot of places have been moving away from the name “master”), “main” is the popular new default, but “development” is a more descriptive alternative.

I think this branch, independent of its name, is essentially beyond redemption. It’s a hodge-podge of things that maybe worked in 2010, things that never worked anywhere, things that work in 9.3/6M62 but not 10.1, things that work in 10.1 but not 11. I recently had to dissuade something thinking that the Friends repo was full of stuff that didn’t work in 10.1 because they’d been getting extensions from master instead of the 10.1 branch.

I’d previously made a pitch for changing “master” to “main” so I’m happy to see it become “development”.

So here’s my suggestion for the future:

We delete the “10.2” branch and add an “11.0” branch. It’ll start empty, but then Nathanael and I can add the stuff we’ve already updated for the forthcoming release. Everything added there will have documentation and examples, be in directory instead of flat-file format (a new v11 feature), and would compile with v11 and not have known bugs.

After 11’s release (which hasn’t been announced: I have no idea when this will be), at such time as the post-11 development-version of Inform has some backwards-incompatible change that would break a v11 extension, we create a “post-11”. We git rm what’s broken. This branch will be highly unstable until we get close to the next release after 11; when that’s released, a new “11.1” or “12.0” will branch off from it. When it’s appropriate, a “post-11.1” or “post-12.0” will branch off of that.

5 Likes
7

I’ll write more about this difference later. Right now, my plain is to, as soon as I can, I hope tonight or tomorrow night

  • update the extensions to directory format
  • run my smoketester to see which work
  • for those that do, increment their version number
  • git add those ones and push a branch with those changes as a new “11.0” branch

(I won’t push yours, @neroden , since you’re doing active development on them.

1 Like
8

I should say that I think the Glk Foundations (ie, the incorporation of Glulx Entry Points into the core kits) is complete, but it’s waiting for Graham to give it a final review and then merge it. Once that’s done we can look at getting the Glk extensions ready for v11.

9

While I agree with most of what @Zed is saying, I think “essentially beyond redemption” is too extreme a description of the now-“development” branch, so I’d be sad it if was just deleted entirely. I’ve been considering it a collection of incomplete “works in progress” which I might pick up and try to turn into something useful. So it’s been a useful source of stuff for me. I’ve picked up some stuff which never worked right, and some stuff which hasn’t worked since version 6G60 (over 12 years ago), and hacked it until it works. I like taking stuff which doesn’t compile and making it work, it’s one of the things I enjoy doing.

I mean, there’s still the even older i7/archive extensions collection, which I use for inspiration, but the ‘development’ branch stuff is usually somewhat more recent. It’s actually convenient for extension development to have a “most recent works in progress” collection, and I’d rather only delete extensions from it if (a) they’re completely obsolete because the functionality is now in Core Inform or has been directly supplanted by another extension with the same interface, or (b) they’re not license-clearable.

If people (such as @Dannii ) would strongly prefer that I “take over” and move the extensions which I fix into my directory, I can do that. I did this with Undo Output Control.

For a lot of them, though, I’ve just been making the minimal changes to make them usable, so I didn’t feel that it was appropriate to take over authorship as I would have if I’d made more opinionated changes. But I did want to update them enough so I actually could use them. And while I could have done that privately, I figured it made more sense to do it on a public branch so @Zed could see what I was doing (ahem!).

The Ron Newcomb and Aaron Reed extensions in particular have some extensive interactions with some of my own extensions (Neutral Standard Responses is a rewrite of Neutral Library Messages by Aaron Reed, which is based on Custom Library Messages by Ron Newcomb, and both of them wrote other extensions which interacted tightly with their own extensions) so I wanted them in a state where I could test the interactions.

Ability-to-test is the same reason I transferred the version-number-suffixed versions from the 10.1 branch for the Jon Ingold and Dave Robinson extensions, and for the ones by @Danni . For the Graham Nelson, Emily Short, and Eric Eve extensions I was just finding it a pain to get the copies of them separately – it is most convenient when I am developing extensions to have the “development” branch checked out and marked as an extra “–nest” to add to every inform build. Most of these didn’t need any actual edits, they just needed to be updated from the copies in the 10.1 branch, or needed the version number in the filename.

I already figured out that the Glk Foundations were going into Inform 10.2 (now 11) so I didn’t work on Glulx Entry Points, but I massaged some other Glx stuff into “compiles for now” format by making the minimal incremental changes for the current version of inform (mostly replacing glk() calls with named calls).

The new directory format for extensions is baroque, though understandable. Are there any plans to retire the very annoying .materials/.inform distinction? I really see no reason why this exists, although the rest of the format makes sense. I suppose I should discuess this on the inform7-evolution mailing list. In addition to making the minimum changes to get things to compile, that’s one reason I haven’t converted any of the extensions to this format during my update work; I was hoping the format would get some cleanup before everything is changed to it.

10

I’m not suggesting getting rid of it; I just don’t think it’s worth pursuing trying to get it to a point of being fit for purpose for any purpose other than: pile of files of stuff.

No. The distinction is there to pander to some silly MacOS thing that I’ve never really understood.

But the forthcoming version comes really close to letting you put everything that matters into .materials alone, allowing one to simply ignore .inform. I have pleaded the case for bridging the gap to no further comment.

2 Likes
11

IMO I see the master/development branch as a scratchpad for people working on extensions. Which is why renaming it to development makes so much sense, we really should have thought of doing that when we first added the I7 release branches. But I do think it should primarily be for people to primarily work on their own extensions, or those they’ve officially taken over (such as my work Flexible Windows.)

IMO, for minor compatibility updates it would be best to do that but submit a pull request for the relevant release branch.

For example: Ron Newcomb extensions: Command Prompt on Cue: update for Inform 10.2… · i7/extensions@5cfbecb · GitHub

This minor compatibility work doesn’t need the author name of the extension to be changed. But I also don’t think it really belongs in the dev branch.

@Zed made a good case for waiting to make a 11.0 branch until it’s much closer to being released, and starting it from a blank commit rather than branching off 10.1.

Maybe what we need is an inform-next branch? Or inform-git? This would be a place to put extensions updated for the Git version of Inform, but without any promise they work with the latest Git version of Inform. (It would be very likely that some extensions get updated to work with Git, only to break later on.) Only once Inform’s at a release candidate stage would we take what’s in inform-git and check what’s ready to be copied into the official 11.0 branch.

2 Likes
12

OK, I’m going to be very explicit on why I think the minor compatbility work does belong in the dev branch. (Though it belongs in other places too.)

I’m doing dev work on my extension. My extension, or the code I’m using to test my extension, needs to depend on another extension by someone else. The other extension needs minor compatibility work. That’s why I updated the extensions I updated on the dev branch.

I want to be able to add one Extensions directory, a checked out “development” branch, to the search path for inform7, and have the development work. I don’t want to have to add four.

An “inform-next” or “inform-git” branch would be fine and desirable; it does correspond more-or-less to what I was using the development branch for, except that I have been updating my own extensions for their own functionality too. Fundamentally, the interaction between extensions is why I needed to update the stuff which I was using while I updated my own extensions.

13

One of the reasons why I don’t think inform-git updates should be in dev is that the original extension’s developer may want to work on their own updates, but perhaps they’re still using 10.1 or 6M62. I’d like for the dev branch to be somewhere they can come back to at any time and have their extensions as they left them.

What if inform-git was branched off of 10.1? So it would have most of the 10.1 extensions, and then any others that need to be updated for inform-git. Do you think that would work well enough for you?

Also note that the idea of a global extensions folder will be going away in future Inform releases. The intent is that only .materials/Extensions will be considered. But you could still copy everything into that folder…

1 Like
14

At risk of pedantry (a risk I valiantly brave daily), I’ll point out, in case any CLI users care, that while the IDE’s will no longer be using the External folder or equivalent, CLI users can do so if they feel like it with the -nest parameter.

2 Likes
15

4 posts were split to a new topic: Inform’s .inform & .materials folders

20

In fact, I specifically requested and got the ability to add an additional --nest from Graham Nelson because it’s necessary for my extension development workflow. I’m preparing a patch to the Linux IDE which allows it to be added in the IDE, and I’m already using the patched version.

Bluntly, if this facility wasn’t available, I’d have to fork Inform. And I’d do it, too. Thankfully Graham was accomodating.

So it’s not nitpicking. This feature is going to be present going forward. It’s only really useful for extension developers but I consider it essential as an extension developer – so it will be present. Either it’s in Graham’s version of inform and Phillip’s version of inform7-ide, which is what it looks like will happen, or I fork both of those and it is permanently present in my versions. So it’s going to be around.

(My workflow pattern: I have five or six games which use the same extension or set of extensions. I update the extensions, then I run through each game to see if they compile and run properly. I am not going to waste my time copying the extension into each game folder after each extension edit; I need them to automatically grab my working copy while I’m developing.)

21

One of the reasons why I don’t think inform-git updates should be in dev is that the original extension’s developer may want to work on their own updates, but perhaps they’re still using 10.1 or 6M62. I’d like for the dev branch to be somewhere they can come back to at any time and have their extensions as they left them.

This is a nice idea. But is anyone actually doing that? Is anyone working on their own extensions, still using 10.1 or 6M62, but also not using the 10.1 or 9.3 branches for their work on their extensions for 10.1 or 6M62 (preparing work-in-progress versions on the development branch)? If anyone’s actually doing this, great, I concede…

What if inform-git was branched off of 10.1? So it would have most of the 10.1 extensions, and then any others that need to be updated for inform-git. Do you think that would work well enough for you?

If inform-git has everything in the 10.1 branch, plus all the stuff I updated for 10.2/11, that’s tolerable. Then I still have to copy over anything else I want to update for inform-git, one at a time – I can do that, because they generally do have to be updated one at a time anyway.

22

An understandable workflow, but wouldn’t soft-linking each .materials/Extensions directory to a central location be much less work than maintaining your own fork of Inform in perpetuity?

2 Likes
23

No, I’ve tried the endless-symlink-farm approach and it’s very annoying, every time I make a new test program. Much easier to maintain a fork of Inform in perpetuity!

Admittedly I probably feel this way because I’ve almost never gotten Inform 7 working out of the box, so I’m getting quite comfortable with running forked-and-patched versions by now.

24

Were you symlinking each extension file? Symlinking the whole Extensions directory would be easier.

2 Likes