Drop support for 5.3? Yes. Absolutely. It's unmaintained. Jump to bleeding edge 5.6? I don't like it because I use 5.5. And I think 5.4 still gets bug fixes, doesn't it?
Making the currently maintained PHP version the minimum requirement sounds like a good guideline. On 25. Februar 2015 10:00:18 MEZ, Christian Grobmeier <[email protected]> wrote: >Actually the question is, if we should go with PHP 5.3 or just take the >fancy features of 5.6. > >Some might argue "we don't need all features necessarily". Thats often >an argument in Java land, and people stick with Java 5 or 6 in some >frameworks because it can be done without. > >I think good and fancy code also attracts committers. Esp in the PHP >world I assume that nicely written, modern PHP based on 5.6 would >attract more people than working code with 5.3. > >5.3 is already phasing out in addition, and I think migrations are done >quicker than in the Java world. > >whats your ideas here? > > > > >On Wed, Feb 25, 2015, at 09:34, Michel Feldheim wrote: >> Thanks guys for clarifying. >> Agree, PSR-4 autoloading would be another improvement. >> Introducing Namespaces increases the PHP requirement from currently >> >=5.2.7 (according to the composer.json) to >=5.3.0 >> >> On 02/24/2015 07:34 PM, Christian Grobmeier wrote: >> > Hey all, >> > >> > On Tue, Feb 24, 2015, at 19:22, Sven Rautenberg wrote: >> >> You must implement the interface as it is, or you wouldn't be >> >> implementing it. >> >> >> > +1. Either implementing it, or not. As Sven said, 3.x can break bc. >We >> > use semver.org. >> > >> > Offering PSR-3 is incompatible. Releasing version 3.0 signals >> > "incompatible to 2.x" all over it. Note that the log levels defined >in >> > the RFC PSR-3 is based on are partly incompatible to the ones of >Log4PHP >> > 2.x. So this will be incompatible in any case. >> > The only chance would be to keep the old interface for conveniance >but >> > make them some kind of bridge to the new interfaces. Not sure if it >is >> > worth the effort though. >> > >> > BTW: Would be nice to use PSR-4 autoloading as well - which means >using >> > namespaces. Which is also incompatible. >> > >> > Absolutely. There is an issue open for that, and I think Ivan >already >> > created a branch working this task. However Ivan is currently >pretty >> > busy, so PRs are surely welcome. >> > >> > My personal taste is to make use of all the fancy new things PHP >has to >> > offer for the moment. They will deprecate soon enough. And if we do >a >> > 3.x then make it proper and shiny. >> > >> > Cheers Christian >> > >> >> On 24. Februar 2015 15:41:57 MEZ, Michel Feldheim >> >> <[email protected]> wrote: >> >>> Hey guys, >> >>> >> >>> working on >> >>> >https://issues.apache.org/jira/browse/LOG4PHP-211?jql=project%20%3D%20LOG4PHP >> >>> >> >>> PSR-3 interface implementation >> >>> >(https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md#13-context) >> >>> >> >>> PSR-3 defines a common interface for logging libraries. >> >>> >> >>> If implementing this interface, the usage of log4php would >slightly >> >>> change. >> >>> >> >>> Currently you can pass any throwable as argument into every log >> >>> method >> >>> >https://github.com/apache/logging-log4php/blob/master/src/main/php/Logger.php#L171 >> >>> >> >>> e.g.$logger->warn('message', $exception); >> >>> >> >>> the PSR-3 interface enforces $context array or null as parameter >> >>> >https://github.com/php-fig/log/blob/master/Psr/Log/LoggerInterface.php#L113 >> >>> e.g.$logger->warn('message {placeholder}, array('placeholder' => >> >>> 'senseless', 'exception' => $exception)); >> >>> >> >>> I could go the strict way and implement their interface, then >3.0.0 >> >>> would not be downward compatible or slightly modify the interface >to >> >>> not enforce type array >> >>> >> >>> What's your preference? >> >> >> > Regards, >> >> >> > Sven >> > >> > >> Sven
