brian d foy

Steven asks "What is your release process". I could have buried my thoughts in the comments, but Dean Hampstead suggested it as a topic for the second edition of Mastering Perl. I started to respond there, but that got a little out of hand too. Whereas Learning Perl and Intermediate Perl are much more "do what I show you because you're new", Mastering Perl is much more "why do we do this?".

There are two opposing ways to go with any process. Your process can be completely external to the actual distribution so that nothing in the distribution is set up to support the process or its automation.

Or, you can create a process and make your distribution match that.

You choose the one that works for you. Don't jump into something without thinking about the long term consequences. Think about it for the next week, no matter what you are doing, whether at work or during a hobby or whatever you do. What's deciding how you do something?

I don't want anything in my distribution, repository, or code to know anything about the tools I use to play with it. But, I should really restate that. I don't want any of my tool choices to affect any of your tool choices. You don't have to use my editor, my tool modules, or anything else to play with the repository. I want to be able to change my process without changing my repository. If I don't like how I was doing things, I don't have to change the things to fix it.

Some people like the second one. Ricardo made Dist::Zilla to handle the hundreds of distributions he's managed, and some other people have started using it too. To work with those repositories, other people need to use Dist::Zilla as well.

I created Module::Release to handle my process. Well, I actually created a program I called release and Ken Williams turned it into the module. My approach was essentially a big shell script. Try this thing by running some external program, look at the result, and decide if I should continue to the next thing. Mostly, I had programmed a bunch of sanity tests--check that the tests pass; check that the disttests pass; ensure the repository is clean; and so on. If everything passed, upload it to PAUSE.

Now comes the next problem. Ricardo and I both made tools that we wanted to use for our own work to exactly match our own process and way of thinking about things. Those tools make it out to the public because that's the sort of people we are.

Other people take the tools we built for our own process and use them. They are on the opposite side of us though. Where our process defines our tool, our tool defines their process. That's almost always a bad relationship with technology. It might be hard to see that in Perl, but I'm sure you've seen how poorly a business is run because you have to submit to what Outlook, Blackberry, or Excel will let you do. It was the subject of my Frozen Perl 2008 keynote presentation.

By letting people use my tools, I had made the mistake I usually make, and will keep making, probably. I put code out there thinking people would take the idea and hack on it, coming up with much different things. But, as with most things, I started supporting feature requests and generalizing things.

I get almost no benefit from supporting other people's features. I already had solved my problem and I had, abut by supporting other people that I'm enabling their ignorance by making it easy for them to adopt a process they don't understand.

Not only that, they are adopting my process, which always has problems even if it is much better than it used to be. I don't care about a perfect process. I care about one that's good enough and doesn't make more work for me. That might not be good enough for other people though, but people tend to use the tool to absolve them of examining what they need.

Choosing a distribution version is a good example, and it's something I haven't automated. Some people change the version when they release, so they can wrap that into the tool that releases the distribution. They then have to live by the rules their tool applies (because, if it's flexible enough, it's not that much different from doing it by hand). I change versions after a release, though. That way, everything I'm doing is already on the new version, which is usually a development version. If the last stable release was 1.23, the next development version is 1.23_01, which leads up to 1.24. I don't think that's the process anyone else should use, but it's worked for me. If my tool did that, people would have to live with it (or not use my tool, which is more likely).

So, the answer is "It depends". Yep, it's still up to you to answer the question for yourself.