Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: A Peeve of Great Pettishness

by sfink (Deacon)
on Oct 28, 2005 at 20:08 UTC ( [id://503757]=note: print w/replies, xml ) Need Help??


in reply to A Peeve of Great Pettishness

I totally agree with at least the spirit of the rant, since it's been one of my pet peeves too. (And it enjoys an honored place on the hearth, not like those dirty little peeves about things that I kinda feel guilty for being annoyed at. They have to live in a hole in the cellar and eat the most rotten table scraps. I'm hoping the sump pump will get rid of them for me some day.)

The most common "standard" that people claim to support, but rarely really do, is:

  • A major version number. Changes in this are a form of warning that backwards compatibility is being intentionally broken. The magnitude of the number has psychological value but no real meaning, except that zero is a special case: zero means use at your own risk because an interface hasn't been established yet that the author is willing to stick to.
  • A minor version number. This gets bumped every time the author believes that some new functionality or bugfix is blessed for use by others.
  • A patchlevel, of uncertain meaning. The magnitude doesn't matter, as long as it's always increasing. Might be a build number, or a date, or whatever. Generally zero means the initial public-ish release of that major.minor.
I used to use very low numbers for my releases, something like 0.01 or whatever. It's an insecurity thing -- you're saying "I think this might be useful, but I may have made some big mistake that you'll all laugh at me for, so I'll put a big label on it saying that I'm not really done with it yet, and I'm very actively working on it and this is just a version that happens to be useful for my simple use case, please don't be angry with me if I never release another version again, ..." etc.

Well, get over it. If it does something useful with a vaguely reasonable API, smack a 1.0 on it. Most CPAN authors spend quite a bit of time polishing things up before their first CPAN release, so calling it 0.1 is disingenuous. And even if you're hesitant about the API, well... you released it, right? So you're saying you'd like other people to try using it? Through the current API, however incomplete and ill-thought-out? Well, then, you must think that something can be accomplished through it, so why not bless it with a big "1.0" even though you're certain that you'll quickly have an interface change afterwards?

If you realize that some part of the API is a huge mistake and should be done totally differently -- what's so bad about calling the next one 2.0? I've found that, as painful as the quick 1.0 -> 2.0 -> 3.0 -> 4.0 succession feels, it almost always slows down dramatically sooner than you expected from the initial phases. And if anyone's using it, you'll have to make enough fixes to produce 2.1, 2.2, 2.3, ..., and by the time you do the 3.0, it'll feel about right.

The "release early, release often" argument is fine, and there really are cases where pre-1.0 versions are more appropriate. But how many projects/modules really have a community of developers or users before they're actually usable for anything? Not many. Users and developers only show up after you've demonstrated the promise with a sample app.

Besides, users are more attracted to versions 1.0 and later, and you want users, right? Right?


I work for Reactrix Systems, and am willing to admit it.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://503757]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2024-03-28 21:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found