Inform 6.35 Release 4 for Unix released

From here on out, I’ll have two current packages of Inform 6 for Unix out at a time. One is pegged to 6.35 (stable) and the other follows 6.36 (development). Once 6.36 is finalized, that’ll become the “stable” release and 6.37 becomes “development”.

If you like, you can install both at the same time. To do this, install what you want as the default first. Then for the alternative, do make install-alt. Remember to do make submodules when you switch between stable and development.

I’ll have a 6.36dev package available in a few days.

As is usual, the tarball(s) is/are available right now at and at the IF Archive in a few days.

Version 6.35 Release 4 (8 October 2021)

  • Rolled back Inform 6 compiler prerelease 6.36 to 6.35. A different
    package will contain that one from now on.

  • Updated PunyInform to version 3.0 commit eba701c4f1.

  • Updated package to allow for multiple versions of the Inform 6
    compiler to be present on the same machine.


Is there a tag or branch I should follow to only get the stable versions from git via I have a build system that semi-automatically refreshes the compiler and punyinform tree from that repository, and it would be nice to switch to one that can track stable if that’s possible.

The current stable branch is 6.35. Version 6.35 Revision 5 and later will appear there. The master branch follows the development release of the Inform 6 Compiler, whichever version that is. When 6.36 is finalized, I’ll make a 6.36 branch which will then become stable. Unfortunately, Git doesn’t allow for multiple names for a single branch.

1 Like

Ah, somehow I had missed the existence of the stable branch, which is exactly what I was hoping for!

edit Ah, it seems it hasn’t been created yet upstream, so I’ll have to manually track 6.35 for now and hope I don’t miss an update later.

There is no branch named stable because Git doesn’t allow a branch to have more than one name. Thinking more on this, I could rework the repo to have a dev branch and reserve the master branch as the stable one. That seems more sensible and it’s early enough for this change to not be disruptive.


Well a branch can’t have more than one name, but you can always have multiple branches pointing at the same commit.

1 Like

Yeah, you can always just keep a separate stable branch and fast-forward merge in changes from 6.35 now, then merge 6.36 when that’s stable, etc. I think the frustrating thing people run into more often here is the immutability of tags (which I only just learned can be deleted!).

But I think that keeping a separate development branch for the latest dev version and keeping your default branch stable suits my use case perfectly, and provides the least surprise.

But all that said, it’s your repo and you’re the one doing the work, so whatever feels most comfortable for your workflow is important!

Git does have aliases for branches using git symbolic-ref. Unfortunately, there’s no way to push an alias to a remote repository, so it’s not really useful here.

I noticed the other night that there was a push that now has master tracking 6.35. Many thanks for this!

1 Like

That sounds great – thanks, David.

1 Like