Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Finally com_mailto allow the usage of a captcha by using JForm #20265
Summary of Changes
Finally com_mailto allow the usage of a captach by using JForm
com_mailto supports captcha's
com_mailto don't supports captcha's
Documentation Changes Required
To be completely honest it's one of those edge cases where you have to outweigh the user benefit with strict adherence to the standard. At this point we're dealing with a weakness in core that could've legitimately just been committed to 3.8.8 as a security fix without this public item but we collectively decided this doesn't need to be committed with that type of "secrecy" (for a lack of a better term). So for me, even though a standard says this strictly must trigger a minor version release, I don't think this absolutely must go into 3.9 and not be addressed in a 3.8 release.
there are a lot more urgent issues which are actually going to b useful that are being held up for 3.9
either we use semver or we dont - its not something that can be done half heartedly
It's not being done half-heartedly. The standard is the guiding line and we have to justify deviating from it (which should be an exceptional basis). It's not "follow the standard when it's convenient". If we followed the standard that strictly then we would have to version bump when we:
So we already do it "half heartedly" in some ways. Considering I can't get good answers on how to handle releases beyond 3.8.x right now the best thing I can do while I'm running releases is use my best judgment on things. And considering the amount of marketing hype that the project likes to put onto .0 releases (and the amount of annoyance end users have if .0 releases don't have something new and shiny, see 3.4 and 3.5 reactions) I doubt anyone would want us doing "full blown" feature releases every 2-3 months as that's about the cycle we're on for something being merged that is not 100% in line with the SemVer definition of a patch release.