Hi Rob,
> > In the comments to his PR (
> > https://github.com/ledgersmb/LedgerSMB/pull/2695#issuecomment-300053021
> ),
> > Rob suggests we should start using
>
> > use v5.14;
>
> Personally, I am not set on any particular version number. And that
> would be most important as it would effect upgraders.
>
> > ... that statement [use v5.14;] also means that we will automatically
> > enable:
>
> > * use strict;
> > * availability of the functions say() and state()
> > * availability of the switch/given construct.
>
> I think those are all minor issues looking at Lsmb as an application or as
> independent modules. These are parsing matters that can be turned on or
> off
> with 'no feature', etc.
>
While true that these features can be disabled, it sounds a bit weird to
enable them by using 'use VERSION;' and then to disable them again by using
'no feature;'.
> > So, the question: do we want to use the 'use VERSION;' statement to set
> the
> > minimal Perl version, with the indicated side-effects?
>
> The big advantages are two.
>
> 1) That 'use v5.14;' does more than require a minimal Perl version. It
> makes a Perl version 5.16 to 5.24 downgrade itself to version 5.14
> preventing accidental collisions with newer features.
>
If new features don't get enabled in newer versions *unless* we use 'use
VERSION;', then if we don't use 'use VERSION;' we're not likely to run into
this clash...
> 2) Put in login.pl and setup.pl 'use VERSION;' will let us crash early
> before much effort is wasted by users.
>
There are multiple places where we can put these:
1. The point where we declare our dependencies: cpanfile
after all, a specific Perl version *is* a dependency
2. The first lines/module which is executed when the webapp is loaded
after all, this is the first (best?) place to let the admin know
executing the code won't work
3. The first lines which are executed when a page is requested in the webapp
this the point you suggest: login.pl and setup.pl
after all, this is a good time to let an unsuspecting user know that
the admin failed to install the correct Perl version
> Testing needs should shrink.
I don't see why you would say that. My thinking is: if a newer version is
going to impersonate an older version, then there's probably new
"impersonation code". New code can have bugs and so we should probably
still run our tests on all versions from lowest to newest.
What the Perl version requirement means to my, by the way, may not be the
same as it means to you: to me, it means "yes, we tested the software on
this Perl version and we think it should work; if it does not, we're
motivated to *make* it work".
Note that the above definition does *not* mean, "we'll actively try to
prevent this application from working on any version prior to X". I'd like
our minimum version requirement to mean "run at your own risk; try if you
might and if it fails, you're on your own".
A rigorous and enforced definition of
> coordinated user/developer platform requirements is just tighter practice.
>
I'm not sure what you mean by this in the context of Open Source Software.
I mean, we can hardly enforce what combination of dependencies and software
versions people will use: many distributions will have their own
"standard"/"shipped" versions. Not supporting those versions (as in:
actively preventing the combination from running) means that packagers
can't package for those distros. Supporting those versions (as in: we'll
try to fix it if it doesn't work) helps packagers help us bring our
software to as many platforms as possible.
>From the developer's perspective, I don't think there is much pain
> involved. I have gone from 5.004 to 5.24 and scarcely noticed anything
> but improvements.
>
Ok. It's good if there's not much pain involved for developers :-) However,
is there also little pain involved for packagers and for end-users? If the
answer there is "yes" then there's no problem to move to this scheme.
However, if the answer is "no, there will be pain involved" then a bit of
pain for the few (the developers) helps aleviate the pain of the masses
(the users).
Note however that I would not call the number of tests we run on all the
supported Perl versions "a pain" -- so little even that I've never
considered anybody might feel that way about it.
> On the other hand:
>
> I have not used this feature much. So, to this point, I am trusting
> the P5Pers are doing it right. I have volunteered to investigate the
> robustness of this feature before any action is taken.
>
> Tighter controls can be a bother--although I don't think this one would
> be much of one in the day to day development.
>
> That a higher 'require XXXXX;' is in some Perl dependency causes a late
> death. This could be avoided by auditing dependencies at setup. This
> is a bit of work but also has merit in itself.
>
> Writing at v5.6 is comfortable.
>
While writing at that version might be comfortable, I've found that I
highly appreciate the '//' operator which is available since 5.10 (for
those unaware, it's the short hand of "(defined X) ? X : <some value>" if
you write "X // <some vaule>".
Currently, this is the main reason to declare that our code depends on
5.10. Because the number of released versions between <newest> and 5.10 is
an ever-growing list, we decided to stop testing 5.10 and 5.12 --
effectively making 5.14 the lowest supported version. The code *might* run
on 5.12 and 5.10 however. (Though it certainly won't on 5.8.)
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
