Slash Boxes
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 ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Tuesday April 07, 2009
01:54 PM

Missing POD Boilerplate

[ #38768 ]

CP5.6.2AN is a great idea, and I'm glad to see it.

However, its existence makes me wonder if the standard CPAN module POD boilerplate is missing a section describing support policy. Many distributions already describe the author's preferred way of handling bug reports, patches, and feature requests, but I can't recall any which limit support to specific versions.

That hasn't been an issue in the past, in part because CPAN encourages upgrading to the most recent version. If older versions will persist, how can authors indicate that they are unsupported?

I realize that many authors disagree with my preferred support policy, and that's fine. I only bring this up because I want to be very clear about how I provide support, so as to avoid unpleasant surprises for everyone later.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • All module authors should be *specific* about their support.

  • I also think this is a great idea (and have suggested such a thing more than once.)

    But I would like to see this be more clear about the fact that it is an abomination (and therefore modules are not supported unless explicitly labeled as such.) The "Report bugs" link does take you through David, so presumably he'll be handling this :-)

    In general, the implicit open-source support policy is pretty straightforward: "if you're using an old version, too bad." Backporters and some authors might be exceptions to

    • I thought it was merely a mirror, so there's no backporting necessary (and no modifications). Certainly if someone forked code I wrote, I wouldn't support even the most recent version. I don't believe there's any forking going on here though.

      • Without doing more reading, I'm only guessing that the thing behaves something like what we were discussing around the time of this thread [].

        That is, without doing any porting, you simply cut everything which doesn't run on 5.6.2 - and if you had an earlier version which did work there, you freeze it at that version.

        Which is why I say "only the latest" is supported. I would probably be more inclined to take bugfixes from an active backporter than against an old version.

        But it's generally more likely that cod

    • "if you're using an old version, too bad."

      Maybe it's unsupported by the author... but I still feel a chance should be offered to the users of this module, as they are interested in using this module, to easily offer bug fixes. Preferably this should require only minimal involvement of the original module author, apart from a "seal of approval", or, on the contrary, the power to veto.

      Does that constitute a fork? Or just a maintenance path of an older version? How would you indicate that in the module version number?

      • Does that constitute a fork?

        It does to me. I don't want to hear anything about old versions of my code, except "I upgraded" or "Thank you". I might point someone to a patch which he or she can backport, but I'm not interested in creating maintenance branches for old code. It's all I can do to maintain current code.

    • In general, the implicit open-source support policy is pretty straightforward: "if you're using an old version, too bad."

      Commercial software pretty much works this way too and it's explicit (upgrade or don't call us). Oracle likes to use the term desupported. They have one extra clause where they will often sell you additional support for an old version at such outlandish rates that upgrading doesn't seem so bad by comparison. But when you don't charge anything, it's hard to mirror this model. :)

      • But it seems to me that chromatic is somewhat mirroring this model. He says that you have to upgrade or you're unsupported. But technically old versions are supported in that you have source code and can do what you want. However he'll charge you in time and energy if you use that option - if you wish to take advantage of that option it will be your time and your energy that you spend, and he'll do nothing to help you share the result with anyone else.

        • That's a clever use of the term "support" -- I like it, but fear many people might find it confusing.

          I do help backporters share their results with other people, however. That's why I choose a copyleft license.

  • I also think this would be useful in general. While the Makefile.PL should list the miniumum supported versions of modules + Perl, it would be nice to be explicit in the docs.

    Should also list the supported versions of underlying libraries etc, as thats often hard to find.