My initial impressions are effectively summarized as "wow, this is long and complex! Does it really need to be so?"
One thought is how thandy/secure updater affects this plan. I see we'll still need to handle alpha vs. stable in some way, but the rest seems to be easier to maintain. From a past packing perspective, having anything more than 2 branches to maintain and build was suboptimal. If package building is automated, it may still be suboptimal, but less of a nuisance because packages magically appears hours after one starts the build farm building packages. I've always viewed -alpha and -stable as feature dependent. -alpha gets new features, -stable is frozen in time with respect to features and only gets bugfixes. In both branches, bugfixes are prominent throughout their lifetimes. Therefore, I propose a simple set of 2 branches, -alpha and -stable. -alpha continues to get new features and bugfixes as we create them. -stable continues to only receive bugfixes on its existing features. When we're happy with the set of features in -alpha, or something else is driving the creation of new and crazy features, we do a feature freeze. Only bugfixes to existing features are included during this phase. When an -alpha switches to -stable, the former -stable is now obsolete and at end of life. The desire for a new -alpha may force the switch to -stable. I think having more than 2 branches creates much more work for us. The previous two paragraphs are perhaps a loose interpretation of what we have done in the recent past. As for operating system support, I'm fine with supporting whatever the current OS manufacturer (for loose meanings of organization that creates the releases) supports. I'd caution this with finding out what our users actually need. There are a many places in the world where they use operating systems from more than 10 years ago. If we truly want to help people, both -alpha and -stable branches should have wide and a variety of OS functionality. As of last winter when I did some testing, Tor (the binary itself) runs under Win98 through Windows 7, OS X 10.3 through 10.6, and Fedora 10 through current. As for packages, I suggest we support the current release of an OS plus two previous versions. We could rely upon the OS versions of libraries rather than bundle our own. In an optimal world, we ship our own libraries for Tor rather than relying upon various vendors to keep up to date. This lets us control features and some part of an operating environment for tor. I'm primarily thinking of zlib, openssl, and libevent 1 or 2 for inclusion here. My idea of an optimal world may need thandy implemented to make it a reality. I think trying to keep lists of OSes and their various libraries is going to create work for little gain. If the OS does not have our minimum requirements, such as openssl 0.9.8, libevent 1.4, etc ,then we cannot run on that OS. Users can build their own tor from source, if so desired. My goals here are to keep things simple. I worry that a complex set of rules for releases will bog us down and not force us to make decisions to keep tor progressing along as it has for the past few years. -- Andrew pgp 0x31B0974B
