OK, I'm sure what I'm about to say will identify me as a total kill- joy who also somehow doesn't remember the bad old days of base/ instability or synchronization issues between base/ and dports/, but please just take it as a given that I DO remember those problems and still feel compelled, given some of the more negative trade-offs I've been seeing, to make the following statement anyway: I don't think MacPorts should be doing releases. Why? Because I think they're premature for the project in general (given where it is in terms of resources and technology), I think they're largely arbitrary in what they're able (or willing) to promise to users and I think that they tend to create more problems than they solve as users attempt to follow the releases for base/ but still want to effectively follow ToT for dports/, leading to something which looks more like FrankenPorts than a genuinely coherent and stable branch. What's worse is the fact that these "releases" are highly misleading in the sense that a "release" for any other software product is something that enjoys not just a "freeze" period but some sort of quality control and testing which ensures that all the respective pieces actually hang together and there aren't any really egregious problems with the product on the date that it ships. MacPorts, on the other hand, does not have any sort of testing infrastructure to guarantee (or hell, even KNOW) that a significant majority of the ports are working at that particular time or that base/ and dports/ synchronization problems have not broken things in various dusty corners of the ports collection. This is why I say that the MacPorts project itself is simply not release-ready; it's more like a project going through its early Alpha stages where "be careful, you might cut yourself!" is about the best advice any user can be given. Of course, we could attempt to dodge the issue here and claim that releases were really only for base/ and dports was the uncharted territory, but that would be silly given that if you add up every single line (of anything) in base/, you're looking at 156,000 lines of Makefiles, C, Tcl and other miscellaneous goop whereas for dports, that number is over 713,000 lines. If anything needs release control, it's dports/, and one possibly helpful analogy would be to suppose that Mac OS X was released every time xnu looked stable enough, never mind everything else that depended on xnu. "Not really our problem", the Mac OS X engineers might say. "People will certainly tell us if Mail, Final Cut Pro or various 3rd party are completely hosed and we can always fix that in the next release." That would sure be a lot easier (and I could spend the bulk of the year on Maui instead of worrying about the bulk of the bugs I worry about) but it wouldn't be a release. 1.4, despite all the hard work people have put into it, is also not a release. Neither was 1.3, or 1.2, or anything that DarwinPorts/ MacPorts has done. They've been fingers stuck in the wind and a highly subjective attempt to decide "what would be a good time" without the benefit of any actual end-to-end testing or regression analysis. If that's all they were, I also probably wouldn't say anything, figuring "ah, what the heck, let the kids have their fun!", but I'm noticing more and more that these pseudo-releases are also a drain on productivity and end up spending cycles doing merges and trying to figure out how to change the behavior of things in base/ in ways that might effects many different ports, even when those improvements are worthwhile. My proposal is that work continue on ToT and this premature notion of releases be dropped until MacPorts is truly ready to run through all of its ports and figure out what's broken and what's not. Speculative development can still be done on branches and need not perturb ToT until all the pieces are ready to come together, but ToT should simply be the commonly-advancing front of MacPorts and if something is broken, a user who tracks it can generally be assured of a fix (either in base/ or dports/ as applicable) simply by keeping their tree up to date and waiting 24 hours. As I've also implied in the previous paragraph, I don't think releases are a bad idea *eventually*, I just don't think it's something MacPorts should be doing until it substantially improves its technology to the point where the general health of MacPorts, and I do mean all the ports and possibly even "their popular variants" are testable. - Jordan