baae319aef
PEAR::Mail updated to 1.2.0 from 1.1.4, fixes deprecation warnings on PHP 5.3, as well as: 1.2.0: • QA release - stable. • Updated minimum dependencies (Net_SMTP, PEAR, PHP) • Doc Bug #15620 Licence change to BSD • Bug #13659 Mail parse error in special condition • Bug #16200 - Security hole allow to read/write Arbitrary File _hasUnclosedQuotes() doesn't properly handle a double slash before an end quote (slusarz@curecanti.org, Bug #9137). • Make sure Net_SMTP is defined when calling getSMTPObject() directly (slusarz@curecanti.org, Bug #13772). • Add addServiceExtensionParameter() to the SMTP driver (slusarz@curecanti.org, Bug #13764). • Add a method to obtain the Net_SMTP object from the SMTP driver (slusarz@curecanti.org, Bug #13766). PEAR::Net_SMTP updated to 1.4.2 from 1.3.1, needed to support updated PEAR::Mail: 1.4.2: • Fixing header string quoting in data(). (Bug #17199) 1.4.1: • The auth() method now includes an optional $tls parameter that determines whether or not TLS should be attempted (if supported by the PHP runtime and the remote SMTP server). This parameter defaults to true. (Bug #16349) • Header data can be specified separately from message body data by passing it as the optional second parameter to ``data()``. This is especially useful when an open file resource is being used to supply message data because it allows header fields (like *Subject:*) to be built dynamically at runtime. (Request #17012) 1.4.0: • The data() method now accepts either a string or a file resource containing the message data. (Request #16962) 1.3.4: • All Net_Socket write failures are now recognized. (Bug #16831) 1.3.3: • Added getGreeting(), for retrieving the server's greeting string. (Request #16066) [needed for PEAR::Mail] • We no longer attempt a TLS connection if we're already using a secure socket. (Bug #16254) • You can now specify a debug output handler via setDebug(). (Request #16420) 1.3.2: • TLS connection only gets started if no AUTH methods are sent. (Bug #14944) |
||
|---|---|---|
| .. | ||
| Auth | ||
| Console | ||
| DB | ||
| HTTP | ||
| MIME | ||
| Net | ||
| PEAR | ||
| Stomp | ||
| System | ||
| XMPPHP | ||
| htmLawed | ||
| libomb | ||
| php-gettext | ||
| Apache2.0.txt | ||
| DB.php | ||
| Mail.php | ||
| OAuth.php | ||
| OAuth_LICENSE.txt | ||
| PEAR.php | ||
| PHP_License_2_02.txt | ||
| PHP_License_3.01.txt | ||
| PHP_Markdown_License.text | ||
| README | ||
| Stomp.php | ||
| Validate.php | ||
| get_temp_dir.php | ||
| gpl-2.0.txt | ||
| lgpl-2.1.txt | ||
| markdown.php | ||
README
DO NOT "FIX" CODE IN THIS DIRECTORY. ONLY UPSTREAM VERSIONS OF SOFTWARE GO IN THIS DIRECTORY. This directory is provided as a courtesy to our users who might be unable or unwilling to find and install libraries we depend on. If we "fix" software in this directory, we hamstring users who do the right thing and keep a single version of upstream libraries in a system-wide library. We introduce subtle and maddening bugs where our code is "accidentally" using the "wrong" library version. We may unwittingly interfere with other software that depends on the canonical release versions of those same libraries! Forking upstream software for trivial reasons makes us bad citizens in the Open Source community and adds unnecessary heartache for our users. Don't make us "that" project. FAQ: Q: What should we do when we find a bug in upstream software? A: First and foremost, REPORT THE BUG, and if possible send in a patch. Watch for a release of the upstream software and integrate with it when it's released. In the meantime, work around the bug, if at all possible. Usually, it's quite possible, if slightly harder or less efficient. Q: What if the bug can't be worked around? A: If the upstream developers have accepted a bug patch, it's undesirable but acceptable to apply that patch to the library in the extlib dir. Ideally, use a release version for upstream or a version control system snapshot. Note that this is a last resort. Q: What if upstream is unresponsive or won't accept a patch? A: Try again. Q: I tried again, and upstream is still unresponsive and nobody's checked on my patch. Now what? A: If the upstream project is moribund and there's a way to adopt it, propose having the StatusNet dev team adopt the project. Or, adopt it yourself. Q: What if there's no upstream authority and it can't be adopted? A: Then we fork it. Make a new name and a new version. Include it in lib/ instead of extlib/, and use the StatusNet_* prefix to change the namespace to avoid collisions. This is a last resort; consult with the rest of the dev group before taking this radical step.