You can prepare the program to react to code changes, though. For example, you can make the child processes to read their source from a file every time and eval it (and maybe check the timestamp before to speed it up). Usual cautions about eval apply.

A couple of neat examples of Live_coding (for different usage cases) perl live coding, hacking perl in nightclubs (ISTR watching a video of this).

There's also Coding for OpenGL "live"

Instead of reloading and recompiling the code before rendering each frame, you can reload and recompile between each job.

I guess it could depend on how your background jobs are called. system and backticks should work the way I expect. Is it something else?

That's a pretty general approach which should help you to implement whatever you like.

I think it fits since problem description was rather general and fuzzy...

(e.g. what does "job" and "compatibility" mean here?)

You might look at the morbo development server bundled with Mojolicious for ideas (or even for a solution). That server is designed to detect source code changes in the Mojolicious app that it is running, and to restart the app upon source change.

My understanding of your question is the following (making it a bit simpler to better clarify): suppose that I have a Perl program running and taking, say, 24 hours to execute. While this job has been running for, say, 12 hours, I want to fire another instance of the same program, but after having modified the code. Will this affect the job that is already running?

If my understanding is correct, then the answer is no, it will not affect the job already running (which will continue to use the old code), and the new job will use new code. The reason for that is that when you fire a Perl program, Perl reads the source into memory, compiles it in memory and generates some form of internal code, and then runs that internal code. Once the internal code has been generated, Perl will not go back to the source code. So the program already running will not be affected by a change in the file containing the source code, because it is never going to go and look at it again. And the new program will happily take the (new) source code as it is when it is launched. So you should not run into any problem.

My apologies if it is me who misunderstood the original question.

Laurent, as one of those contributors of a “complicated answer” ... and framing this response, of course, as merely an impersonal, technical discussion among software engineers ... I think it might be useful here for me to elaborate on the thoughts that guided my particular suggestion.   (Not to defend, per se, but rather to illustrate ...)

To my way of thinking, an over-arching technical consideration of “a program that takes 24 hours to execute” is that the very non-zero possibility exists that this program might, (koff, koff ... say it isn’t so ... say that my pager didn’t just go off at OMGwhattimeisit?...) run for 23.75 hours.

Oops.™

And so, like it or not, that job must be re-run.   Exactly that job.   ...   Provably that job.

If you have replaced the original source-code ... the code that existed at the precise moment when that job was launched ... with another version of the same source-code, then you by-definition cannot “exactly, provably, re-create” that job.

“Well, okay, is that actually an issue?”   Only the OP can tell, but my “forever err on the side of caution” tacit assumption was that it might be.   And this, for the record, is the thinking that therefore guided my previous suggestion.

“Engineering-appropriate prudence?”   “Feechur?”   “Unnecessary complication?”   Only the OP (and his business case) can know for sure.   And, I think, from an engineering point of view, both opinions stand.

Sure there are many questions linked to version control and related issues, it is worth bringing them up, I had just the feeling that most answers were not really answering the question. But as I said, it may be me who misunderstood the initial question.
Je suis Charlie.

I suggest that you need to be explicit about it ... if a job needs to be restarted or repeated, it needs to be able to run the same thing.   One simple way to do it would be to write a stub script that searches for the latest (e.g. last filename, where the filenames are soandso.##.pm), then requires that file and invokes its main method.

This allows you to explicitly keep every successive version of the software until you choose to discard or to archive it.   The stub-script should also be written so that you can specify the module-name to be loaded, on the command line, if you need to explicitly specify which one to run.   And I would never re-use a filename.