RFC: nightly build and patch policy

Your thoughts on the utility of the following are solicited.  

Our current release practice is:

1.  build a snapshot of CVS HEAD every night
2.  release every year or so
3.  provide a point release (e.g. 0.82.1) as needed

My sense is that FreeTDS would be more useful to people using the release
(as opposed to CVS HEAD nightly snapshots) if they had an easier way to
get/apply the latest bugfixes.  One can always use CVS to generate a
patch, but that's quite a bit of work and beyond many people's skill set. 


I propose instead:

1.  same
2.  same
3.  same

4.  Build the current release branch "snapshot" nightly.  This would
provide a "rolling current" of bugfixes to the lastest release.  The
tarball would be named freetds-stable-patched.tar.gz.  The sources would
unpack in a directory named "freetds-[ver].dev.[date] where [ver] is the
pending release (i.e. 0.82.1 today) and [date] is in the usual yyyymmdd
form.  

5.  Post a freetds-stable.patch file that comprises the output of "CVS
diff -r [release]" where [release] is the release's tag in CVS.  

Were this policy in place now, you would find two new files in
http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/:

1.  freetds-stable-patched.tar.gz, which unpacks as 
	freetds-0.82.1.dev.20080618, and 
2.  freetds-stable.patch, which contains everything needed to convert
freetds-0.82.tar.gz into freetds-stable-patched.tar.gz.  

I might revise the naming conventions slightly, but the purpose and
content of the files wouldn't change.  

Now that I've cooked up this idea, I'd like a reality check from the real
world.  Would it be helpful?  Would you use the new files?  Inquiring
minds want to know.  

Yours humbly, 

--jkl