generic-build-script extension to update version numbers in README

[Charles Wilson]

> Hey you guys, you're going to recreate whole package build management
> systems like debian has it, or gentoo, or even slackware.  

Yes, there is a fine line here.  IF we want a true, full, pkg build 
management system we'd do better not to reinvent the wheel.  But this 
impacts the package-delivery system as well: setup.exe.  If you use 
dpkg/rpm/emerge for build management, do you teach setup about 
dpkg/rpm/emerge files?  Or do you abandon setup.exe and start over, with 
some gui driver for dpkg/rpm/emerge -- and teach that gui about 
replace-inuse-files and other cygwin/win32 trivia?

But note the initial 'IF'.  I'm not sure we DO want a full, build 
management system.  How high a bar do you want to set for new package 
maintainers?  Right now, editing a script is a fairly simple task for a 
newbie ... I fear "buildscript.sh.in" and getting a 'maintainer toolset' 
set up.  That's why I've suggested that the basic gbs stay the same; 
only add-on features would be external.  And newbies could learn _those_ 
on an as-needed basis, because the core gbs (as customized per-package) 
has everything that's truly NEEDED to get a build working.

> What about
> a GUI for this?  Maybe based on Qt, so at least maintainers are forced
> to install and use at least 90% of all Cygwin packages which would
> increase usability over the years.

Gerrit, are you volunteering to take over management of all of my packages?

I have no intention of installing either KDE, Qt, GTK, or Gnome on my 
windows box.  If I want those GUIs, I'll run them on a linux box and not 
thru an emulation layer, thankyouverymuch.

Let's NEVER get in the habit of saying "...we should FORCE maintainers 
to...".  I like the FREE software culture because it is FREE, and not 
driven by authoritarian control freaks (although the Debian Social 
Contract makes me wonder sometimes).  Please don't turn cygwin into a 
controlfreakhive.

--
Chuck