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

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.
  • This has come up a few times on Perlmonks.org, like this one [perlmonks.org]. I think people should just start at 1.0. A version number of 1.0 means "first release", not "I will never change this again." I hear people say they don't want to go to 1.0 because they feel it is a promise that the API is set in stone, but that doesn't seem to stop commercial vendors, and realistically there will never be a time when you know the interface is perfect. I have witnessed non-Perl people freaking out over sub-1.0 version numbers
    • 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.3
      • 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.
        • 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.
  • It's funny you should mention this. Handel is currently in a state of going from 0.32 -> 1.0. I was saving 1.0 for something more like "the API will change to get rid of silly alpha thoughts", and it's also a big gutting, and conversion from CDBI to DBIC.

    But even as a lowly 0.32 version, it has quite the large set of tests and I'd consider it mature, just not mature to where I have no regrets about the API.
    • 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 :)
      • (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: htt [handelframework.com]
        • 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 th
          • > 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 lea
  • 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 v

    • 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.

      • 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 Clas
      • So we should base our actions on what unthinking idiots are doing? No thanks.
        • 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.

        • 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.