Large sub-projects == slow releases?? (Re: [Twisted-Python] twisted.vfs issues - web2 dependency)

Mary Gardiner mary-twisted at
Thu Sep 29 17:27:12 EDT 2005

On Thu, Sep 29, 2005, glyph at wrote:
> web2 should not be a trivial HTTP server with a small resource wrapper
> in it.  It should be a full-featured web server.  Web does not mean
> "http" - all web-related protocols, such as WebDAV, ftp, even SOAP or
> Gopher, should be part of the 'web server' product part of Twisted.

My understanding of the original purpose of the split -- which is
probably wrong -- though was to allow parts of twisted to release
without massive dependencies on near unrelated release critical bugs,
and further to allow users of multiple bits of Twisted to not have to
upgrade them all as a lump. If we have a model where an enormous group
of request-response protocols are lumped with web, we return to the
following release management problems:

 1. rapidly evolving code, like FTP, which seems to have some parts
    working now and were it an independent project should probably be
    having some highly alpha releases, will not be released until it is
    sufficiently stable to be bundled with a more used and mature protocol
    like HTTP, and may in turn block said releases by being highly

 2. relatively unrelated code, like ftp, or the hypotheticals above,
    will need to go unreleased every time there is a major years-long
    rewrite of a large component (web2)

My understanding of the release-early-release-often philosophy was to
encourage early adopting users (who are also more likely to become
contributors). As it is, no sub-project is releasing and core looks set
for a pretty slow ongoing release cycle. I may be naive about this, but
my concern is that while core has critical mass in terms of users, the
protocols and applications largely don't, and won't until they are seen
by potential users to be active and supported, part of which is actually
releasing. Having users in turn has been known to spur development. What
you're proposing sounds like a mature release policy: as in,
sub-projects will be rather monolithic and will release when they're
mature. Is this correct, and if so, will they release?


More information about the Twisted-Python mailing list