Familiar Release Strategy

Greetings,
    Now that v0.4 is out, and I've received a share of comments/bugs/requests against it,
and dealt with a couple release headaches, I've decided to implement a new system for
actually performing releases. I'd like to get input on it.

[Releases and Feeds]

I'm interested in introducing the concept of release and feeds into the current
way we do things.

A feed is a constantly updated stream of packages that are available. There
can be different flavors of feeds, the initial (and probably only) feeds
being ``stable'' and ``unstable'' (i.e. /familiar/feeds/{stable|unstable}). A
release is an immutable, versioned, captured-in-time, copy of the current
stable feed.

When new packages are created, they are added to the unstable feed. When the
package is at a point where the stable feed auxiliary is happy with it, it gets
moved into the stable feed.

When the stable feed is at a point where functionality has increased enough
to warrant a new release (or there's a bug that needs to be fixed), the release
engineer takes a snapshot of the stable feed, and prepares a new numbered release,
the given number being at the release engineer's discretion.

Initially, anyone installing a given release will have an ipkg config file setup
to only download packages from the same tree as the release
(e.g. /familiar/releases/v0.4). Thus insuring that they get only the packages
known working when the release was created.

If a user wants to track the current head of the stable or unstable feeds, s/he
would download the appropriate latest versioned release, and change their
config file to point to the appropriate feed (possibly using some type of
unwritten configurator). At some point, we might even have special feed
snapshots when there were major changes that couldn't be conveyed by ipkg
upgrading packages.

--
I need to do a formal write-up for the docs, but above is the initial stab.  I'm
thinking of rolling out this technique for v0.4.1, due this weekend.  Tell me
what you think.
Alexander