Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

jonasbn
  reversethis-{gro.napc} {ta} {nbsanoj}
http://e-diot.dk/
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Friday December 07, 2007
02:52 PM

Release based development vs. ?

[ #35060 ]

I am very much a release person. I work with Perl everyday and I attempt to use the concept of releases in as much as can. Another thing I use a lot is the CPAN distribution format.

Using the CPAN distribution format gives me a lot of great tools to distribute my work over several machines like test and production environments, sometimes it seems overkill if you want to test a very little thing, which is hard to test in your development environment, which is for me is my workstation, but I am also getting better at that part.

Well the release gives me the control over my distributions over time and when something is finished I tag it in CVS and create a release just as I do with my CPAN contributions.

But sometimes I am not the only one working on the code base, projects and assignments, which is ok.

But right now I am in a situation where I am closing projects for two other developers which is also okay, but the situation is somewhat, hmmm... chaotic.

The code I am supposed to finalize and put in production is in CVS (most of it), which at least is a beginning, but none of the projects was quite finished so I need to find out what state they are in, what the state of their dependencies are and get things finished.

And all I have is HEAD and the CVS log.

The CVS log can assist much in this, but I would have loved a Changes file since some of these applications are huge. I will get back to this is another journal entry.

By now I have things in CVS and I have tagged things, so I can get back to a state prior to my intervention and I can start to roll things into the test environment and start the test. Unfortunately some of the dependencies are not completely up to date, so it is very much a phase of experimenting, changing committing, releasing and testing...

So I am getting somewhere - slowly.

But one thing I do not understand about all this, is why are people not thinking in releases? I have subclasses Module::Build to suit our need and more and more of our applications are using it even though they will never go on CPAN. I version all of my releases and distributions so I can track what features get introduced where do I can clearly mark the dependencies, since I want to be warned at build time not at run time when deploying.

I understand and acknowledge the following arguments:

The process of releasing is to much work, you have to update versions numbers, make sure things are okay and tag stuff in CVS

Then automate the process so it is not so difficult, check Module::Release or something?

Small updates and fixes are easier to apply directly where the code is running

But what if the code is running in several places and do you remember to remove debugging statements, reset debugging flags and everything back into CVS.

So what other arguments are there NOT to use versioned releases, shipped as distributions, your reflections on the topic are most welcome, since I simply cannot work without process also as a mental tool and I do not really see an alternative other than chaos.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.