Version Control Policies

[Chris Vail]

Just a general question for all Sysadmins in large environments: how do you do rollouts of languages and compilers?

Our situation is that we have really old PERL versions in production--one going back to 5.0.2. The developers want to develop in the current version, which is 5.8. Currently, HP is supporting 5.6.1. So far, we've been unsuccessful in compiling 5.8 with all the various and sundry modules. We can compile one or t'other, but not all at the same time with the same compiler. This is the development environment, so its not a big deal--YET. But moving this into production is gonna be really, really ugly.
So, what do y'all do? Do you set a version of the language and compiler and stay with it until its no longer supported? Or do you constantly update? Do you take only the supported HP version? How long do you keep it before upgrading?

When we were a startup, things went so fast that there was no time to set and maintain a policy. Now we're at the policy setting stage, and I'm wondering what everyone else is doing.


Chris

[A. Clay Stephenson · Accepted solution]

That's a tough one. First, all of your applicable Perl scripts should have "require 5.6.0;" (or whatever) statement in them. My rule is that I will update to any Perl version for which there exists a binary distribution in all target environments. I have no problem getting the binary distributions from www.perl.org/CPAN (as opposed to the HP releases). Until fairly recently, HP's Perl was very obsolete (Perl 4) thus CPAN is your better source for all platforms.

Compilers are more problematic. My rule there is to upgrade something like every six months to the latest version that is available on all platforms. If a patch is required to fix things like "possible data corruption" then those get applied immediately.

Your developers need to get into a "lowest common denominator" mode so that they avoid the latest bells and whistle's until they are available on all the target platforms -- at least in production. I have no problem with developers using the latest versions as long as they are restricted to the development (as opposed to the production) environment.

Everything should be under some sort of version control system and even Perl scripts should be produced by makefiles. In some cases I use the C preprocessor to create Perl (or Shell) scripts so that #ifdef's can be employed.

[Chris Vail]

Clay--
What compiler(s) do you use? We've tried a couple versions of gcc and a couple of versions of the HP C compilers, yet nothing works all the time in every circumstance. Do you use version control on your compilers? Just a few minutes ago, I got the Linux porting kit which has yet another compiler, and I'll try that one next. The developers are really bugging my boss to get 5.8 installed and compiled.



Chris

[A. Clay Stephenson]

For HP-UX, I use aCC and ANSI/C; I've never been a huge fan of the Gnu compilers/assemblers but they are certainly worth the money.

I never use any Perl modules that require C source and a compile/link to install; moreover, I try to avoid the use of any modules that don't come the a standard Perl distribution. If I need those specialized functions, I generally write them in C where I have full control over the makefiles. Often, all that is really needed is communication via pipes with a sqlplus session.

If you move into an environment that requires you to compile and link Perl with herds of modules which also require compiles and installation then that can quickly become a deployment nightmare unless you build swinstall or pkgadd scripts for every platform --- and that ain't easy.

If your developers are really keen to move to 5.8.x (as opposed to 5.6.x) then surely they have a handy-dandy list of 5.8.x features that are not available in 5.6.x and THAT THEY ACTUALLY PLAN TO USE.