DBD-Oracle-1.91_1: The minimum required Perl version

[twata1]

Hello,

Is the minimum required Perl version now 5.30.3?
I don't know which versions of Perl are supported by other distributions.

Thank you,

[Tux]

Other distributions? Like Linux distributions or DBD releases of other database interfaces?

The official window is IIRC 10 years, which would now be perl-5.20.2
Due to some slow mainstream distributions, the current baseline is either 5.12 or 5.16 depending on author opinion

[twata1]

Thanks for your reply.

Other distributions? Like Linux distributions or DBD releases of other database interfaces?
Linux distributions.

I thought that for some people using Linux, the minimal Perl version upgrade might have an impact.

Thank you,

[ancientwizard]

2cents. Feel free to reference any Perl you care to. I'm more interested in dropping old Oracle support, but that may be tricky when I explain a new issue I'm facing and observations I've made during exploration.

I offered 5.30.3 because it's what I use in the office. Here is why; Before that I was using 5.14.N (or it was 5.12) because it as the most like perl 5.10.N (which was found on RHEL6), stable and pretty much bug free. Every version of Perl I tried to use inclusive of 5.16 - 5.28 had issues, various bugs, and memory leaks. I reported the memory leak, and I believe 5.30 is when the issues were corrected (5.28 may of had some of the issues corrected but no all); OR at least I was unable to detect (my specific leak tests no longer failed). At the moment my Perl versions of choice are 5.30.3 & 5.32.1.

Besides I'm thinking that older Perl's can use the older DBD::Oracle module version and older Oracle. I don't see an advantage of having the latest DBD:Oracle if you're living in the past.

I have been testing with 5.34+ and all of them have an issue I'm still trying to reproduce in a small-ish script. Nothing to do with Oracle or SEGV. I'll report that to the Perl peeps when I have something for them to run.

[Grinnz]

This minimum version appears to have been autogenerated from this new test file: https://github.com/perl5-dbi/DBD-Oracle/blob/master/t/91-segv-fork.t

There is no reason for this library to require Perl 5.30, or to increase its previous minimum version of 5.8. If the provided test file truly requires Perl 5.30, then it should start with a skip_all declaration that skips the file unless running on a version that recent, and allow the module to function as previous on every other version.

[Grinnz]

I offered 5.30.3 because it's what I use in the office. Here is why; Before that I was using 5.14.N (or it was 5.12) because it as the most like perl 5.10.N (which was found on RHEL6), stable and pretty much bug free. Every version of Perl I tried to use inclusive of 5.16 - 5.28 had issues, various bugs, and memory leaks. I reported the memory leak, and I believe 5.30 is when the issues were corrected (5.28 may of had some of the issues corrected but no all); OR at least I was unable to detect (my specific leak tests no longer failed). At the moment my Perl versions of choice are 5.30.3 & 5.32.1.

Besides I'm thinking that older Perl's can use the older DBD::Oracle module version and older Oracle. I don't see an advantage of having the latest DBD:Oracle if you're living in the past.

It is not this module's responsibility to cease functioning on Perls with bugs that do not prevent it from functioning. There are many reasons a new version of this module may be desired on an old version of Perl. Perhaps it would be worth increasing (to the extent necessary) for a breaking issue, but this isn't that.

[ancientwizard]

I offered 5.30.3 because it's what I use in the office. Here is why; Before that I was using 5.14.N (or it was 5.12) because it as the most like perl 5.10.N (which was found on RHEL6), stable and pretty much bug free. Every version of Perl I tried to use inclusive of 5.16 - 5.28 had issues, various bugs, and memory leaks. I reported the memory leak, and I believe 5.30 is when the issues were corrected (5.28 may of had some of the issues corrected but no all); OR at least I was unable to detect (my specific leak tests no longer failed). At the moment my Perl versions of choice are 5.30.3 & 5.32.1.
Besides I'm thinking that older Perl's can use the older DBD::Oracle module version and older Oracle. I don't see an advantage of having the latest DBD:Oracle if you're living in the past.

It is not this module's responsibility to cease functioning on Perls with bugs that do not prevent it from functioning. There are many reasons a new version of this module may be desired on an old version of Perl. Perhaps it would be worth increasing (to the extent necessary) for a breaking issue, but this isn't that.

You're reading too much into my sharing. I offered it simply as history and experience not to cut them off. If anything, my opinion is only that this module holds onto the deep past far too hard and complicates support and testing. I'm certainly not going to test any of this on older Perls or older Oracle versions.

Perl 5.30 isn't a requirement; it's a holdover from when this was just a script I stared in the office to reproduce the issue I was seeing before it became a test here. I'll remove the line from my fork for a future pull request with another bug fix I'm chasing; it's a don't care! I should have removed it.

[djzort]

@twata1 Only a developer version has been sent to cpan, so its good that you have pointed out this now so it can be corrected.

[djzort]

older Perl's can use the older DBD::Oracle module version and older Oracle. I don't see an advantage of having the latest DBD:Oracle if you're living in the past.

I'm not going to be judgemental on the constraints people have on their production environment. It's great to have you with us and I am glad people take the time to contribute issues and patches.

Saying that, I continue to strongly urge people not to just "cpanminus DBD::Oracle" in to their production environment because there are simply too many variables to consider (perl versions, oracle versions, your os version etc).

Instead, mirror this git repo in to your org's private repos and set up a CI pipeline* with your specific versions and enable all the tests. Even add more tests specific to your needs.

[*] Terminology may vary depending on your systems. If you happen to have gitlab its fairly trivial to adapt the github actions. Other systems shouldnt be too hard and this repo includes docker bits to get you started. Even a nightly cron pull and test would likely provide most of the value without a web ui

[Tux]

There is three levels defined

• required : the minimum version the release needs to function at all. This does not mean it will function bug-free or "safe". It is up to the end-user to decide weather they take that risk
• recommended : the minimum version the author thinks the module works as expected without risk
• suggested : the minimum version the author thinks the end-user will have nothing to worry about

To me, required is the lowest version that the module/release will build against. If I have that version, and it fails tests on that version, I will alter the test file to skip the failing test if it is due to that version and not to blame on the module. e.g. using 64bit plus UTF-8 for DBD::mySQL is something that will most likely cause havoc. If the end-user however can assure not to use 64bit or Unicode, who are you to deny that?
recommended is the version that should be stated for the lowest version that has not public CVE's and can assure that the module builds with and passes all tests (under regular circumstances: you cannot guarantee there is enough disk space or the other end has ruined their system beyond repair)
suggested is the minimum version you feel absolutely comfortable with, e.g. the highest version you work with yourself and develop your module with

[djzort]

This should be resolved in https://metacpan.org/release/ZARQUON/DBD-Oracle-1.91_2