For most CPAN authors, version numbering is a pretty simple concept.
You start at 0.01, and you add one each time you do a release.
Eventually some time around 0.28 you sort of run out of things to do, it gets another release here and there, and some time about 0.33 it pretty much doesn't change. It may as well be done.
You recommend the module to people, it works well enough you don't do a release for 2 years. Dozens of other CPAN modules and hundreds of developers quite happily use it.
But what you aren't hearing is that out there in the darkpan and particularly when you have people having to get modules approved for use, there are people that care about versions. They don't know Perl as well as you do, they aren't inside the "mirror ball" (of which this journal is a part).
All THEY see is a version number, and it's a 0.XX. It's not finished. Does this mean it breaks? Or has features missing? Will the author change the module on me in 6 months time and break back-compatibility? Will my boss let me use a module with a version like 0.12? These are all questions that get asked.
The trouble for authors is that, almost by definition, they will _never_ see this happening. If the person had the brains (and sometimes the guts, since some people find contacting authors intimidating) they would ask the author, and you'd tell them it was totally stable.
But since they DON'T ask you, you'll never see them.
So, the answer to the question I hear from time to time from authors, "What's the version number got to do with it?" is "Because sometimes the version number is all people have to go by!".
So we have two choices. Lose those as users and keep doing what we are doing, or at some point make the switch to a 1.XX version number. Stealing a habit from another author, I've taken to just switching the "0" to "1" and leaving the second number intact (if it is reasonably low at least) so that those truly in-the-know see what change there has been.
Having chosen to move to 1.XX (assuming you make this choice) the question is then "When should I change to 1.XX?".
So to share my personal guideline for when I move something over, here's my conditions for when I move one of my modules from 0.XX to 1.XX. (I go through and apply this every 3 months or so)
1. The module is feature-complete
2. I myself can't think of any major flaws in the code (although there may be POD and testing nigglies still)
3. The module has been at zero rt.cpan.org bugs for 12 months
The large modules like PPI that need a more controlled 1.000 process are few and far between, and for those the question of "when 1.00" is much more obvious.
But if you are looking at one of my smaller modules, and you see it is at 1.XX, then you can know it's been bug-free for at least one 12 month period.
As a bonus for moving to 1.XX I have reports from a number of authors, and I've seen myself, that the number of users, thank you emails and bug reports can go up significantly after toggling the version to 1.XX.
So there's at least a little bit of empirical evidence for the phenomenom.
If only we had CPAN Statistics (but that's another big kettle of fish).
Re:I agree
Alias on 2006-05-23T23:00:55
It would be a mistake, I think, to start at 1.0.
Lying about "going 1.0" is almost as bad.
Commercial vendors regularly put out a shit half-finished barely working release and marketing calls it 1.0.
The open source world _generally_ (there are of course exceptions) only goes 1.0 once it's truly "stable".
That is both a plus, and means you will get held to a higher standard.
And people using Open Source software are going to be much more annoyed when you 1.0 release changes 30 times before you get to version 5.32 (looks towards Catalyst). They expect more from you.
The exception are that, exceptions. They shouldn't be seen as an excuse for you to not follow the "most expected practices" as well.Re:I agree
perrin on 2006-05-23T23:18:41
It's not "lying" to release something as 1.0 unless you had some agreement about 1.0 means and it isn't meeting that. As a result of the practices you're describing, I think most people expect 1.0 to mean it works but still has a long way to go. Among the manager crowd that you're discussing, people will often say that 1.0 is too new to try, and they'll wait for the point release.Re:I agree
Alias on 2006-05-24T01:47:46
While it may not be written down, merely by the fact it's a CPAN module you are going to inherit by default an implicit agreement that 1.00 is "stable".
And I agree with the 1.00 thing, which is why I move from 0.12 to 1.13, but only when it's _really_ stable.
It's accurate and keeps everyone happy.
Re:Nice timing
Alias on 2006-05-24T04:33:10
Ditto to you.
I just got asked about a shopping cart, and I keep trying to find an excuse to try out Handel.
Of course, I think it might be a good idea to wait a bit until you get 1.0 done.
And I'd love to see some sort of mock up generator that you can somehow enter a combination of features and settings and it dumps out the basics for that application.
But I'm sure it will all arrive in good time:) Re:Nice timing
jk2addict on 2006-05-24T12:50:36
(Not trying to steal this thread...:-)
It's safe to say you can give 0.32 a try and still be mostly fine when 1.0 hits. The major change is the RETURN_AS crap in load()/items(). Instead of doing magic, it always always returns an iterator in scalar context, and the list of objects in list context: even if there is only one result. Aside from that, I'm striving to keep the API the same, and using a [mostly unaltered except for the iterator change mentioned) test suite. For some 1.0 changes/thoughts, see: http://handelframework.com/wiki/1.0
As far as the features/mockup thingy, it currently has helpers for catalyst to generate a basic framework, much like the/demos/catalyst/ part of the site, also like the perl.com article. The real answer is, there is no feature set. :-) Handel is a pure cart/order i/o layer, with a plugin based checkout oder processing pipeline; not an out of the box solution.
There is a Catalyst based ecommerce "solution", I'm in the planning stages of called Mango, which I'll hit hard as soon as 1.0 is done. Of course *gasp*, it will use Handel for the core cart/order/checkout stuffs. If there are any features you are after in such a thing, feel free to add them to: http://handelframework.com/wiki/Mango::ProposedFeatures/ramble_mode=off Re:Nice timing
Alias on 2006-05-25T14:21:13
Well, I don't do shopping carts. But I know people that do.
And the dominant model seems to be that people want a fairly straight forward out of box with common features, but not overloaded with them.
And then EVERY shopping cart is going to need something different, from "coupon" support to Australianised Postage modelling to VOIP "talk to a consultant".
There's always going to be one or two new things, but they almost always need to be different.
So what I personally would want is something that deals with the common features that you need in, say, 80% of cases. And then I want it to be a easy to add new features as possible, while STILL being easy enough to hack in my own features.
And I want to be able to use it whether the client's budget is less than $1,000 or up to $100,000.
I think Handel/Catalyst is the right concept for the base on which to build such a thing. But I'm not so sure you can create the ideal solution by just adding features...
Maybe a combination of documentation and plugins.
For each feature, you provide a list of plugins to install, then provide documentation on linking in the feature... or something.
It could be tricky to get it right, but it might be worth it.Re:Nice timing
jk2addict on 2006-05-25T23:17:47
> There's always going to be one or two new things, but they almost always need to be different.
Right. In fact that's the entire premise of Handel::Checkout. By default, it does nothing. Since everyone needs something different, it's just a plugin loader to shove and order thru, with some basic phases added in (INIT, VALIDATE, AUTHORIZE, DELIVERY, etc), with the ability to add custom phases till the cows come home.
As far as the Mango stuff, I don't think it's going to be an uber solution. At the very least, it's more of web interface around handel, with some other stuff thrown in.
I prefer to look at the Changes log, rather than the version. A decent Changes log will tell you how the project has evolved and give you an indication of its stability. I've dismissed several modules based on their Changes logs. Small versions don't bother me so much, if the author has simply incremented by 0.01 each time they released to CPAN. Even jumps in versions don't annoy me, as long as there's a clear, consistent reason behind it (for example API changes). I'm particularly annoyed, however, when version numbers are artificially inflated with no apparent good reason. I won't mention names, but web app frameworks seem to tend to have this problem!
Re:Changes
sigzero on 2006-05-23T22:58:19
I think you missed the point. The programmers aren't complaining.
when you have people having to get modules approved for use, there are people that care about versions.It is the $boss, who hasn't a clue about Perl (he would write it as PERL), who is looking at version numbers.
Re:Changes
Alias on 2006-05-24T01:28:13
Indeed.
And zero-versions can make $bosses nervous.
Of course, you have to balance that against the problem of going to 1 too early and scaring the developers.
If 1.0 isn't stable, and lets assume they are fairly clueless just-getting-stuff-done Perl-as-a-better-sh etc types, how are they to judge when it is done?
Looking at, for example, Module::Install, the Changes file won't help them much to know that out of all the versions, 0.61 is the first version considered "safe'ish for early adopters".
Or look at Class::Inspector's Changes file. I went to 1.0 too early on that one. Who's to know when it's "done"?
Compare that with the Test::SubCalls Changes file, which now has a stable version number, and for those reading the Changes file makes an obvious and definite step from 0.XX to 1.XX.
When faced with a situation in which you have _extremely_ limited knowledge based on your ability with Perl itself, which of the two makes it appear more clearly that the module is "done" now.Re:Changes
slanning on 2006-05-25T15:03:18
So we should base our actions on what unthinking idiots are doing? No thanks.Re:Changes
chromatic on 2006-05-25T16:37:14
Yes, it's important to help prop up companies where the ultimate technical authority is in people who have no business making technical decisions because... aw hey, I can't finish this sentence with a straight face.
Re:Changes
Alias on 2006-05-26T01:31:32
Just because you don't like it doesn't make it wrong.
You are giving away software, at the core it's an altruistic activity.
Giving away functionality and then getting elitist about how it gets used is one of the things that people really hate about Open Source.
