What I said was that in most development projects that are very long, the “target” and “scheduled for” should be starting to coincide – however that tends to hold only when the assumption is that “testing was not relegated to the last weeks (days !?) of release.”
I clearly didn’t say that was the case for Inform. Again: how would I know?
But if a multi-year development cycle fails to meet a targeted and/or scheduled date, it’s usually because problems cropped up in testing or, rather, as a result of testing. If you still have open bugs, for example, and if your policy is to release only when all bugs are closed, then clearly testing is going on right down to the wire. If that’s the case, any release date has to be provisional until you know the results of your tests. I don’t think anything I just said is too surprising. Not sure how this led you to asking me when testing began.
The only bugs that are open in the Core Inform project on the bug tracker are ones that have been reported since April 3, so this seems like a deliberate irrelevance.
This thread has veered into “how many angels can dance on the head of a pin” territory – and also, I don’t really care one way or the other, though (just to be clear) I am eagerly looking forward to checking out the new release. But I would suggest that possibly the new version is being tested (by somebody or other) prior to release, and that bugs are being reported directly to Graham rather than filed in the bug tracker. At least I hope it’s being tested. The reports I glanced at on the bug tracker page seem to be for 6G60, so either the new version is not being tested or reports are being made privately.
That being the case, “deliberate irrelevance” is not, I think, correct.
Well, this is in fact the case; a couple of reports from Aaron Reed showed up on the bug tracker and then vanished with a note that bug reports on pre-release builds should be sent to Graham. And of course it would be nuts not to test the new release. But as far as the “close every bug” policy goes, I was under the impression that that meant that every bug on the old version should be closed before the new one is released, and that happened a little while ago.
Also worth noting that “testing continues until (close to) the release date” is different from “testing is relegated to the weeks (or days) before release” in obvious ways.
Well said – the waterfall-ish notion of a separate testing phase is rather outdated, to say the least, and you’d have to have a very special corporate mindset to apply software development strategies designed for teams with 100+ members when you have a mainly one-man hobbyist project.
Inform is nearly ready; at this point, only polish tasks are being done, and these should be locked down tomorrow, as I understand it. There are then additional steps that go into distributing finished builds that may mean it doesn’t reach the rest of the world until a few days into May. This is partly a matter of coordinating the work of the various volunteers who need to participate. But I don’t expect there to be any significant delay at this point.
As to testing, Graham has periodically distributed builds for testing particular new aspects of Inform over the development cycle, as well as running the battery of automated tests to verify its behavior during development.
I agree. But then again as people point out: we shouldn’t (necessarily) attribute the standards of the industry to “volunteer” projects. If we did, we’d have to say that multi-year release cycles are outdated, even on “mainly one-man hobbyist projects.” Fast, iterative releases with a minimum of functionality that can be easily tested and allow for course corrections is viable on any sort of project but particularly for the “one-man” types. That was my point: as long as testing is not relegated to some end phase, then the pace of development doesn’t matter as much. When testing is relegated to an end phase, things get … problematic.
Personally, I’m fine with the pace of Inform development. I think insight into the development process – for any sort of project – is the most important. It’s what keeps a community engaged and interested beyond just having a fun tool to play with. And I think we have that with Inform.
I think some (or at least one) were taking my comments as being critical about Inform, even though I very clearly and unambiguously said I would prefer Inform 7 be released when ready, not just because a given date has arrived. As David said, I’m excited to see what’s been done. I’m not a huge text adventure fan but Inform is definitely one of the more interesting (and exciting) projects around.
While we’re waiting with bated breath, let me point to something that wasn’t mentioned in the summary a month ago: improved support for Vorple. See vorple-if.com/outgribe/2014/vorp … ighlights/ for a few details of release 2.5, which is supposed to come bundled with the pending release of I7.
I don’t know about “bated breath”, but it’s certainly on my mind; making me poke around my Zifmia code, my unfinished Win8 version of Shadow, and one of the many WIPs I have.
About that: How drastic are these changes going to be, anyway? I’ve only been in the IF scene for a very short time, so I’m not really aware of how different each update is. Will there be a lot to learn that’s new; how much, if anything, will be deprecated or removed; to what extent might older code need to be rewritten to accommodate the update?