Best way to manage package versions?

[AlfaProject]

Hello ,
We are using Perl in our project, soon we will have few additional programmers working on a same project.
Today I'm using regular 'require' to get all other .pm files with functions.
Now I thinking how we will work with that, if other programmers will edit one of the functions file and make an error , it will crush all program.
Maybe best way to move all code to packages, and use 'use' package function to get functions I need.
The problem is how I manage versions of packages if one of the programmers want to make an update for some code in a package ?
What approaches Perl have for this situation ?
I don't want to use third party storage like git or programs that will manage it automatically.
Just searching for best logical approach for this
Thanks

[Corion]

Having multiple programmers change files without supervision and logging is a recipe for sure disaster.

I recommend using any kind of source code control. My favourite is git (not GitHub, which is just some website), but there are many others, such as simple file copying, or rcs, or cvs.

Having source control also makes releases easy - you can conveniently wind time back to find the exact module versions active for a given point in time. The Perl developers use git to do just that.

[blue_cowdawg]

We are using Perl in our project, soon we will have few additional programmers working on a same project. Today I'm using regular 'require' to get all other .pm files with functions.

Any time there is a team of more than one the following disciplines should be enforced (IMHO):

• Change Control: meaning some form of formal tracking of who is changing what and what the purpose of the change is and an understanding of the impact.
  This is crucial in preventing miscommunications both within the team and between the team and stakeholders and aids in the credibility of the team itself. This can be a simple as a spreadsheet to using Trac to something more complex. In some situation pre-qualification and change approval meetings should be held prior to changes being made. These can be as simple as sitting down with a stake holder and validating that the changes you are about to make fit within their needs/desires.
• Version Control: This is one area you should not fool around with or minimize.
  Pick a system that works for the entire team such as Subversion, GIT, CVS or any of a myriad of solutions out there. Even my own personal programming projects are all subject to version control under Subversion. If nothing else it gives you the luxury of "falling back" to a previous version if things go sideways.
• TEST TEST TEST!! Taking the time to write tests for your modules and/or programs (scripts?) will pay you back in dividends later on in terms of fewer bug reports or complaints from your customer community be it external customers or just (!) your boss. Get familiar with the Test::* family of CPAN modules. You'll be glad you did.

I'm not sure what you mean by this:

Today I'm using regular 'require' to get all other .pm files with functions. Now I thinking how we will work with that, if other programmers will edit one of the functions file and make an error , it will crush all program. Maybe best way to move all code to packages, and use 'use' package function to get functions I need.
the left hand expression makes no sense in context with the right hand expression.

If you are writing modules there is one approach, if you are writing (for lack of better word) libraries of functions there is another. To my way of thinking modules are self contained cohesive units that mimic an object oriented system. (whew!) I stop just short of making parallels between Perl modules and C++ (or Java) classes. They are not quite the same although there is some resemblance.

If I create a file "Foo.pm" and put in it:

sub a { 
     print "letter a";
}

sub b {
     print "letter b";
}

sub mother_mary {
     print "whispers softly";
}
1;

and in a Perl script use:

require Foo;

mother_mary();
print " ";
b();
print "\n";

When I run the above code I get:

$ perl require.pl 
whispers softly Letter B

BUT! if I change this to a true module such that:

package Foo;
sub a{
        print "Letter A";
}
sub b{
        print "Letter B";
}
sub mother_mary {
        print "whispers softly";

}
1;

something completely different happens:

$ perl require.pl 
Undefined subroutine &main::mother_mary called at require.pl line 3.

something completely different happens. The three subs in "Foo.pm" are no longer in the main context but become part of their own context "Foo". You can get around that by using Exporter and friends and possibly using export tags to group functions together.

My personal preference though would be to have a code review and figure out what groups of functions should be grouped together as object oriented modules. Maybe you can make your code much more organized and have more effective units for unit testing. Key thought being make your modules as self contained as possible.

[vsespb]

Either you have

1. One project with several modules/files. Use Git or Subversion. If one programmer broke the code, you will be able to revert this change. If you are not sure if programmer break code or no - use unit/integration tests.

2. One project with several files, but you wish to distribute different files/modules independently. Different computers/module users will have different versions of modules installed. Then you need put version for each module, and think about compatibility between version. This is about release management, and much more complicated that (1). Example is CPAN

Try use (1).

Also if your files/modules contain perl 'packages' use 'use', not require, unless you have good reason (for example, you decide runtime which module to load)

And always use version control systems (like Subversion/Git/Mercurial etc) unless you're writing something very very small to be deployed on one computer and you are alone.

[jandrew]

I absolutely agree that version control is essential. And it is always easier to use one of the existing setups rather than roll you own version control. My personal favorite is git. With that said, version control alone will not resolve the incompatible updates you describe. You need to add centralized testing to version control. It can be as easy as Test::Harness or as tricky as a Jenkins server.

[tobias_hofer]

Hello



Putting code into packages is essential for collaborative development as source control (like git and so on)is. Take the time to make a clear structure/design or even a collaboration diagram how are things working right now and what is actually required.

This way you may finds possible Issues which may come to picture in 6 month and that may be too late for changes. Once I have had to debug my own code written some months ago with quick-hacks where packages are spread over several files. This was quite tough :-) and I could blame myself for. Spend some time for that, it is worth!


Cheers!
Tobias

[larryk]

First of all, congratulations on having the foresight to even ask this question. I've worked with many people who didn't realise that team growth can lead to code compatibility problems. So well done!

To answer your question, you need three things:

• change control for your code.
• test cases that verify the functionality of your code.
• a "Continuous Integration" system that checks out the latest code (from change control), runs the test cases and tells the originator of the change (which is also known from change control) that their change broke a test.
That's how you find out asap that a change has broken something.

You say you don't want to use 3rd-party software for this, but I'm really not sure how you can avoid it.

Perl can help you with the test item above - there are many test libraries which enable you to write simple test cases, run them and report the results. Just write `perldoc Test` on the command line for the most basic intro.

For change control you should consider git. git is actually very simple for basic use. You don't need to learn much to get started and if your team is writing commercial code (i.e. it has some value) then you should really be using a change control system anyway. Don't fear it. Take a look at http://git-scm.com/book/en/Getting-Started-Git-Basics

For Continuous Integration (or CI, as we like to call it :), you can try Jenkins from www.jenkins-ci.org - it's also free and quite simple to set up so that it gets your source code from git for every single change that any developer submits into git, runs all the test cases automatically across everyone's components and then emails the person who made the change (and anyone else who is interested) if any of the test cases fails.

You can of course do all this manually instead of using git/Jenkins or other similar tools, but that's going to become a cost to your team. So it's really up to you.

Good luck, and remember that the cost of fixing a bug is proportional to the length of time it takes you to find it.

[TomDLux]

I think you're saying that some module M.pm gets a new version, v1.1, which should be used for certain programs, but other programs should continue to use v1.0. At one company where I was, they had a special module to handle that. When you use that module, you specify at the same time the modules you want to use, and the version for each. By combine a standard prefic, the module name and the version string, the module generated directories to add onto the PERL5LIB path, so that the correct versions were found when the modules were invoked.