On 2008-05-21 02:49, Richard Freeman wrote: > > Using Git means developing in branches and keeping trunk stable > > is possible so a continuous rolling release from a persistent > > source URL can work. > > Please - not another "production-quality" project that only uses code > repository checkouts in place of releases.
No reason why timed tarball snapshots can't be also released. > I've never seen this work successfully. No two users end up running the > same code. The code can't possibly be as stable after merging in some > huge branch as it was the day before. It can be if the right procedure is followed. The central Git repo has 3 (or more) "well known" branches; "unstable" where obviously any initial test patches get merged, "testing" where patches that survive in unstable for a certain time get moved to, and "master" (HEAD in svn/cvs speak) is considered "stable". Developers expose their own patches in unstable, adventurous end users dabble with the testing branch and most folks would use master, which could optionally be released as tarballs as well. > Now, if the URL you mention is tied to EXACTLY one version of the > source, that would be better. That is essentially a release under a > different name. Exactly that. > I can't see the sorts of people who would use something as robust as > DSPAM wanting to know that they're the only person on the planet using a > particular release of the code. n/a > ALL code has bugs. A release process simply makes it easier to track > what those bugs are and manage them separately from new features... What I've outlined provides exposure to all 3 important levels of code development, the inital new patches, code that is probably okay but needs wider testing, and the final cut that could be as stable as any dedicated tarball release. The real benefits are that everyone is *easily* in sync with each level without having to install a new tarball from scratch from a URL that just changed, ie; the whole process can be more easily scripted and automated. This could happen with any VCS but I suggest Git because it's fast, makes branching a breeze and everyone with a checkout has the entire history and can push/pull to anyone else. The current method of becoming aware of a new release, find the unique URL of said release on webpage or mailing-list, manually download source or binaries, perhaps build then install, reconfigure new installation, test... could be refined. Also, a continous rolling release allows for micro-updates which can be a lot safer than any 3, 6 or 12 month release with a lot of updated code. --markc !DSPAM:1011,483310d4150924754219709!
