The 1.7.8 to-do list

Submitted by javelin on Thu, 2004-02-26 13:57

Many people ask me when they can expect PennMUSH 1.7.8 to be released, so I thought I'd take a chance to talk about it.

Actually, I'm going to reframe the question first, by turning it around: why are you anxious for 1.7.8? Or, put another way, you can already have most of 1.7.8: use 1.7.7.

Some background: PennMUSH releases follow two tracks, which we (perhaps unfortunately) label "stable" (the even-numbered minor versions, like 1.7.6) and "development" (the odd-numbered versions, like 1.7.7). The stable branch is only updated for bugfixes - new features are rarely, if ever, added. The goal of this branch is to provide an unchanging feature base that is as bug-free as possible. The development branch is updated for both bugfixes and new features. New features may introduce new bugs, of course. Once the development branch reaches a state of Release Goodness (see below), we stop adding features onto it for a little while, and when it doesn't show bugs for a time, its final release is renamed into the new stable release.

I say that the stable/development labels may be unfortunate because they seem to imply that the development branch is unstable. In fact, while this is usually true for early patchlevels of a development release, the reverse is often the case for later patchlevels, especially if your definition of stability includes security, expected behavior, and resource management, all of which tend to get upgrades during development. What isn't stable is the feature set, because it's growing in the development version. Maybe the labels should be be stagnant/active.

So what's this Release Goodness that determines when 1.7.7pX becomes 1.7.8p0. Typically, it consists of two things:

  1. We don't have any features that are partially implemented or broken - all the new features added in this branch have been completely and properly implemented. That is, we don't start a new development branch until we're pretty much happy with the existing one.
  2. We want to add big new features that require so much reworking or reconceptualizing that it's unlikely to go right at first, and we want to freeze a known working codebase before we do it. That is, we start a new development branch when we really want to tear things up.

Because those 'big new features' are usually added in very early patchlevels of the development code, a corollary is that late patchlevels of the development code tend to look a lot like what the new stable branch will. Particularly since we often strive to preserve compatibility in the hardcode API (e.g. the non-static functions), there's no need to wait to port hardcoded systems to 1.7.8 -- port them to 1.7.7 now. The 1.7.7->1.7.8 transition will be a simple one (as the final patch is usually little more than changing the version numbering). 1.7.6->1.7.8 will be just as hard as 1.7.6->1.7.7p(latest).

Ok, the part you're waiting for: what's left before 1.7.7 becomes 1.7.8? Well, here's my working list (crossed off means they're done!):

  • Talek has more optimization work on chunk migration code that he wants to finish.
  • Javelin has partially completed transitioning the power system to use the same internals as the new flag system, and needs to complete that.
  • Some changes to the restart script and other places are contemplated to make startups and dumps more foolproof in unusual cases.
  • Some new things with @command and @hook to be added
  • Attribute trees will probably support automatic creation of non-existent branches when leaves are set (&A`B me=foo will add &A if it's not there)
  • Several smaller bits and bobs that will increase stability in unusual situations or fix a few outstanding bugs.

What will the 1.7.8 release look like then, in terms of major changes from 1.7.6?

  • Telnet window size negotiation
  • #true and #false boolexp atoms
  • Attributes: @descformat, @debugforwardlist
  • Attribute trees
  • Generalized lock failure framework
  • get_objdata()/set_objdata() internals
  • Flag/power system rewrite
  • Channel recall buffers, notitles, nonames, nocemit privs
  • Wildcard help command
  • Interactions
  • Chunk memory allocator
  • Ancestor objects
  • Per-command logging
  • No more minimal.db (autogenerated)
  • SSL
  • SQL connectivity
  • Attribute DEBUG and VEILED flags
  • Commands: ], @hook stuff, [, @sql, empty, new 'give' form
  • Matcher rewrite
  • Many compile-time options now runtime or removed
  • Flags/powers: MISTRUST, can_nspemit, HEAVY, sql_ok
  • Configs: max_global_fns, unconnected_idle_timeout, max_guests
  • Customizable configs
  • Object ids
  • Functions: lpos, *lflags, scan, accname/%~, children, powers, strreplace, fraction, root, terminfo, lports, digest, cowner, baseconv, tr, hostname, ipaddr, cmds, reswitch*, firstof, allof, nscemit, sql, sqlescape
  • Decoupling No_Pay and HEAVY qualities from ROYALTY/WIZARD flags.
  • Anonymous attributes with #lambda

So, don't wait, act now - upgrade to 1.7.7. :)