in reply to Re: What is YOUR Development Process?
in thread What is YOUR Development Process?
The question was how to handle the inter-dependence of these items, not how to version them.
What are non-application modules?
CGI::Application uses a model where you take the normal if/else ladder analyzing the input and create a module with different methods that get called for different input. You create an "instance" script that sets any paramters and calls this module. Non-application modules would be modules that are used by the application module, but don't assume I/O via the web (and thus would include My::Module as well as DBI). There's nothing magical about it: It's just a standardization of what people did without a framework.
Describe a non-multi-user-environment
My personal machine, where a check out can be owned by me with no problems, vs the shared machines.
you typically tag all of the files you want for a release and then checkout everything with that tag.
If application Foo depends on module Baz, and Application Bar depends on a newer version, how do you mark those dependencies? What if the required module is not of your authorship, such as a DBD, and thus not in the version control? Do you tag every file in the dependency chain? That could get very long and puts extra effort on the tagging process.
No offense, but your answers are exactly the kind of material I've been seeing. "use version control" without telling me how to synchronize files of different types. "Describe a non-multi-user-environment" when the apparent majority of perl developers are in shops of only one or two people, and very much effectively not multi-user development/ "rsync the files to your production machines" when I'm worried about making sure all the proper files are copied and tests pass. Your answers may be correct, but they don't actually tell me what I need to be able to implement a real system.