2009/6/25 Karsten Bräckelmann <[email protected]>:
> See bug 5574. Even 2 years ago we where "having a hard time supporting"
> 5.6 (as you put it so nicely ;), because there was no infrastructure to
> test compatibility on the devs end.

If we needed to install perl 5.6 somewhere, we could do so.  It's not
terribly difficult to get it installed w/ the required modules.
That said, the argument here is basically that we collectively seem to
have little time or interest to support 5.6.  So in the open-source
"if this is important to you, pony up some time and handle it" way,
drop it and let someone handle it if they really have a problem with
it.

> Also, keep the nasty hacks in mind (bug 6131), which effectively means
> we are incompatible with the latest Perl, for the sake of Perl 5.6
> compatibility. That's a bad trade-off.

Sure.  My POV is that we should make SA focus on Perl 5.8, and then if
there need to be a few small hacks to work on 5.6 that's fine.  If we
find that "a few small hacks" is really "not feasible" or "large and
annoying hacks", then sure.

To be honest, I haven't been following things w/ SA in a while, so
there could well be a lot of issues that I don't know about and so
yeah drop 5.6 support.  But if it's not a lot of work to keep it
going, we may as well do so IMO.  In the realm of "if it's not broke
...", I would assume those folks using 5.6 because it's stable don't
want to be forced into upgrading it (and deal with the likely crap-ton
of dependency issues) just because of SA.


This reminds me that this was one of the purposes of the sa-update
User-Agent setting...  It would let us track some versioning
information from clients.  Perhaps we should add $] for future
versions?  Not that we actually have ever done anything w/ this
information...

Reply via email to