These things are orthogonal:
The build script is the mechanism that, upon invocation on freshly checked-out source tree, yields a complete build of required targets and dependencies. It could simply be 'make all' if you've got a makefile, or a suitable invocation of MSBuild, Ant, Maven or Scons. If you have a complex hierarchy of dependencies or related projects, your 'build script' may be a top-level file that invokes each of them in turn, checking for success as you go.
The build script is just one script of possibly many - checkout, build, test, package - but you could have an all-in-one mechanism controlled by command line params - it depends on your environment.
The build server, or rather continuous integration server, is the automation mechanism responsible for scheduling/triggering, monitoring and reporting of the checkout -> build -> test -> package -> stage -> deploy pipeline. You could use cron/Task Scheduler if you had nothing more sophisticated to hand, but there are many excellent tools now such as Jenkins, Cruise Control, TeamCity, etc.
It is important that you can invoke a build without using the CI server, in the case that it is busy/offline/unreachable/otherwise-unavailable, so therefore the logic to get the build/test/whatever done needs to be outside of the CI system, but is invokable by it, parameterized by branch/build type/version/architecture, etc.
First off, there is no correct way.
However, I have found that keeping all version numbers the same across releases, regardless of whether things have changed or not, makes things much easier down the road. If I want to know what has been going on in a software, all I want is to be able to easily go from a version number to a state in version control, and see whats going on in there. Having a collection of unrelated version numbers makes doing that murky.
The alternative is that ultimately you have to maintain some sort of BOM for your software releases to know what's what, and those invariable end up out of date or incorrect, and everything just becomes a big mess.
There have been situations I've worked on where products did have a mismatch of version numbers for various dlls. It was a medical device software, and the developers rationalized that by not changing certain parts, they could avoid doing testing and verification for those parts. It may have saved work there, but it has created plenty of other work and harmed credibility with distributors when even the company wasn't sure what was what because of the hard to understand versioning scheme.
Best Answer
I've never seen it written out in that form. Where I work, we are using the form
MAJOR.MINOR.REVISION.BUILDNUMBER, where:For example, a revision may be released to QA (quality control), and they come back with an issue which requires a change. The bug would be fixed, and released back to QA with the same REVISION number, but an incremented BUILDNUMBER.