how to deal with patches?

[Scott A. McIntyre]

>       How would you guys like to handle these patches?
>    Do they represent unstable release 2.0.1 code, or simple
>    patches for 2.0.0?  Should patches go out immediately
>    and managed in a separate area on the web site?
>    Should I mail patches to the argus mailing list automatically?
>    Should I go ahead and release 2.0.1?  How about
>    argus-2.0.1.beta.1a?  .... Just kidding ;o)

Can we go back to letters, start over with an A release?  ;-)

Personally, I'd like to see a few things:

1)  Use of CVS for these incremental changes prior to the next .x
number; the core functionality of argus wasn't really changed, no new
features added, and if I had to make a guess not a lot of folks noticed
any problems (/me coughs).

2)  A context diff / patch for these minor fixes to apply to 2.0.0, to
create 2.0.1

3)  Inform the mailing list(s) of the availability of the patch(es) and
what they apply to; let folks decide if they want/need to bother
retreiving.

However, as you point out, it's a bit silly to have minor version
upgrades every week or two, so perhaps tie it to some arbitrary event,
calendar month, 5 patches, etc.  End of the month and all patches that
were applied creates the next minor version number increment, or, after
getting a good handful of issues resolved/patched, increment.

Until then, notification of changes and use of CVS for the
brave/foolhardy would do me nicely.

I'd prefer not to have versions like 2.0.182-p38, though, whatever
happens.  

Scott