Best practices to upgrade a compilation server to 11.31.

[Olivier Masse]

During our upgrade to 11.31, our custom application has continued being built on 11.23, and executed on a mix of 11.23 and 11.31... the reasoning being that code compiled with aC++ on 11.23 is upward compatible with 11.31, while the reverse isn't true.

Our development process consists of one or two versions per year, and a bunch of patches within these releases.

My question: When we decide to migrate our build server to 11.31, I'm wondering if we'll absolutely need to build a new complete release or simply start on a Monday morning compiling patches?

I'm not a developer but as a sysadmin, I favor a new release for the simple reason that I'm not familiar at all with this. But building a new release will be a PITA and I better have arguments if I go recommending this process.

Any insight on this will be appreciated.

Thanks

[Steven E. Protter]

Shalom,

The answer depends on the code itself. The tools and OS 11.23 and 11.31 are pretty similar.

I would recommend to the development team a dual process.

I would continue to run as you have until you can run a test.

>>
the reasoning being that code compiled with aC++ on 11.23 is upward compatible with 11.31, while the reverse isn't true.
<<

Not necessarily true. If the libraries are the same your code might work both ways. If your code takes advantage of an OS feature or system in 11.31 call in 11.23 then you might have trouble.

The key is to test.

If your tests come out okay, you can fully migrate to 11.31. You may as many software developers have to do, maintain two compilation environments and have 11.23 and 11.31 versions. The test data will make that clear.

SEP

[Dennis Handly]

>the reasoning being that code compiled with aC++ on 11.23 is upward compatible with 11.31

Yes, unless you have an illegal or kernel intrusive application.

>I'm wondering if we'll absolutely need to build a new complete release or simply start on a Monday morning compiling patches?

It's up to you as long as you test everything. If you are trying to eliminate testing, then changing as few things as possible may make you more confident.

>But building a new release will be a PITA

How? It will take longer? And how long is that?
Are you using the same aC++ version on 11.23 and 11.31?

(Are you not running on 11.23 any more?)

>SEP: If your code takes advantage of an OS feature or system in 11.31 call in 11.23 then you might have trouble.

Even if you use the same features, bug fixes on 11.31 may make it fail on 11.23. I saw a case where a system header changed and the value passed to a system call was different.
But the most important reason is that it isn't supported.

[Olivier Masse]

I'll be updating aCC too (no reason to stick to the old version we currently have).

Within a few weeks I'll have no servers left at 11.31 except that development server.

The best would be to do the upgrade at the same time they start development of a new release, but there will be issues as the same dev server is used to develop future releases and make patches for legacy releases. Reason: "That's the way it's been done for years".

Thanks

[Dennis Handly]

>I'll be updating aCC too.

A.06.25 will be releasing soon.

>Within a few weeks I'll have no servers left at 11.31 except that development server.

That makes it easy.

>but there will be issues as the same dev server is used to develop future releases and make patches for legacy releases. Reason: "That's the way it's been done for years".

Oops, that locks you into 11.23 on that build server. (It's a very good reason, it's the only way to be supported.)

[Steven E. Protter]

Shalom,

Comes down to it, the drop dead date for 11.23 (and 11.11) is December 31, 2013.

So migrating your software and compile operations to 11.31 is the way to go long term.

I would build a new release on 11.31 and do rigorous testing on all platforms you support.

It might be a good idea to wait for the next compiler release. Really though, the application developers need to buy into this process. It is their responsibility to know what their code does on what platform.

If anyone wants to direct comments directly to me, my profile contains contact information. My general policy (oft broken) is to communicate with the thread poster, not my fellow answer givers within the context of the thread.

My original statement needs a correction.

Unless you are using unsupported features, or system calls specific to 11.31, your software should run on both platforms.

I highly recommend two compile environments and the same version of the compiler on both systems.

SEP

[Dennis Handly]

>but there will be issues as the same dev server is used to develop future releases and make patches for legacy releases.

>ME: that locks you into 11.23 on that build server.

Oops, as long as you are updating ALL of your machines to 11.31, even those running the legacy releases, you are free to go to 11.31.

[James R. Ferguson]

Hi:

> SEP: If anyone wants to direct comments directly to me, my profile contains contact information. My general policy (oft broken) is to communicate with the thread poster, not my fellow answer givers within the context of the thread.

Why? The give-and-take between among all of us is what adds the value to this community database.

...JRF...

[Duncan Edmonstone]

Olivier,

>> The best would be to do the upgrade at the same time they start development of a new release, but there will be issues as the same dev server is used to develop future releases and make patches for legacy releases. Reason: "That's the way it's been done for years".


Any reason you can't keep an old 11.23 image around in a HPVM? wouldn't need much resource I expect just to do builds if you think that's necessary

HTH

Duncan

[Dennis Handly]

>Duncan: wouldn't need much resource I expect just to do builds

During compilation it would need 100% of a CPU and you'll probably want to do a parallel make of at least 4 CPUs.

[Olivier Masse]

I thought of the standby VM solution but as Dennis pointed, building with one CPU would be doable but could take a long while and I don't have any spare capacity available.

We'll probably end up testing if patches built with 11.31 are fine and if there is any issue, I'll recommend compiling a special point release under 11.31.

Thanks everyone

[Dennis Handly]

>We'll probably end up testing if patches built with 11.31 are fine

They should be.

You didn't see this here but you could use the unsupported SDKROOT:
http://docs.hp.com/en/14487/commandsyntax.htm#sdkroot
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=e2086d6e1de021106d6e1de02110275d6e10RCRD

[Steven E. Protter]

Shalom again,

I think a HPVM based solution will let you maintain two compile and test environments.

You can temporarily assign extra cpu's to your 11.23 VM when the horsepower is needed to do a compile, and then assign them to other VM systems after the compile is done.

Higher utilization of expensive computer resources, always a good thing.

SEP

[Olivier Masse]

Closing thread.

Possibilities include a dual environment using HPVM, SDKROOT, or simply upgrading in the middle of a release cycle and be done with it. I'll subit these choices to the developers.

Thanks everyone