Just a small follow up on this question for those who are interested in this topic.
On Sat, Aug 2, 2008 at 1:52 AM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > No, I'm not. What I want is to stop cooking things that are already > done. Sometimes I really think that Mark Shuttleworth is right WRT > time-based releases, man, this would make this project so good, SO > GOOD that I can't even imagine. From the technical to the social side. IMHO, I also like the idea of time-based releases. As a reference I'll put up two examples that I think are nice: 1) http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux This is about the version numbering, but IMHO is essentially a recognition from the developers (or at least Linus), that thinking about 1.0, 1.2, 2.6.26 for Linux doesn't make much sense anymore. They detached releases from features. If the new feature is ready for this one, it goes in this release. If not, cook a bit more and appear in the next. 2) https://fedoraproject.org/wiki/Releases/10/FeatureList Fedora is a Linux distribution. Here's a simplification of how it works: they organize the releases by proposing new features (whoever is going to hack propose them) for the release and keeping a status about them. The ones that are 100% when it's freeze time are in. The others not ready are moved back to proposed for the next release. I guess what Ubuntu folks do is similar. The "overhead" of releasing can be as simple as build some scripts to bump stuff up and generate tarballs (btw, raster already has its asparagus script that does something similar :-)...). Or am I missing something here?[*] Maybe people disagree on *what* should be called a "release"? Were the asparagus snapshots "releases"? (maybe my understanding of "what is a release" is too weak, I don't exclude that possibility) Or even people disagree on where should we start with these time-boxed releases? [*] btw, if you're wondering how could we do something like "let's take this part out if not ready" in the code, branches can help you with that, do the new features in "topic branches" and then integrate to "main tree" when they are ok. You can even keep a tree up with all those ongoing features, for people testing if you want (that's similar to what people call "next" tree in some projects). But I'm really not pushing git or anything here, I think this "cherry picking" of features is less important right now than the other questions. Cheers, Caio Marcelo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
