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

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

    Perhaps "backported by" or "superseded" messages -- maybe an index of that sort of stuff.

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