Geeklog 1.7.0

This release adds support for PostgreSQL (in addition to MySQL and MS SQL), developed by Stan Palatnik during the Google Summer of Code 2009. It also adds a re-authentication option in case the CSRF token expires, thus preventing loss of data. For other improvements, please see the list of changes. Of course, it also addresses the latest security issue.

We would also like to thank all those students again who applied for the Google Summer of Code 2010 and submitted patches for Geeklog. Some of them already made it into 1.7.0, the rest is scheduled for inclusion into Geeklog 1.7.1. We will also be looking into adding more of our successful GSoC projects from 2009 into that release.

A word of thanks also goes out to our translators for making Geeklog available in so many different languages. We could use some more help here, though, as some of the translations haven't been updated in a while.

Please note that we raised the minimum requirements slightly for Geeklog 1.7.0: You now need PHP 4.4.0 or later and MySQL 4.0.18 or later to run Geeklog. We will drop support for PHP 4 entirely with Geeklog 1.8.0 later this year.

Note: The Geeklog demo site has since been updated as well (thanks, Michael). So now you can try out Geeklog 1.7.0 before installing it.

[...] Geeklog 1.5.2sr6 (1.5.2 "Combo" update or upgrade from 1.5.2sr5) Other versions: The issue is also fixed in Geeklog 1.7.0 (but present in the 1.7.0 beta and release candidate). The 1.5.2sr6 upgrade can also be used for Geeklog 1.6.0, 1.5.1, [...] [read more]

It should always be known this version was special. It's the premiere and a great start to [story:new-slogan#release-cycle the new release cycle], which will hopefully take Geeklog to new grounds.

As for translators, it would boost motivation if you had a list of all translators/translations with versions, for example:English - [user:User X] - currentPirate - [user:User Y] - v1.6.1 (link to v1.6.1's story so we'd see its date)Latin - [user:User Z] - v1.3.0 (link to v1.3.0's story so we'd see its date)(I've used languages which Geeklog lacks, so no translator will be offended).

The less updated a language is, the more chance there is it's "abandoned" (i.e. ripe for a "takeover").

The requirement for PHP 4.4.0 will make difficult (if not impossible) to upgrade for users of Red Hat Enterprise Linux 4 and CentOS 4 (specially if they are in a shared hosting service), mainly because these Linux distros are tied to (a patched) PHP 4.3.9.

I'm in this situation. My provider said they will upgrade OS of the server until 2012, and it is out of question to install another version of PHP because security policies. So, I'm stuck with currente Geeklog version until 2012.

And here I thought we were the conservatives ones ... PHP 4 has been dead now for 1.5 years. By the time Geeklog 1.8 will be out, it will be over 2 years. So it makes sense to drop support for it then.

I didn't expect this minor step up to PHP 4.4.0 to be a problem, as I was expecting everybody who's still holding on to PHP 4 to at least run the last version (PHP 4.4.9). For the time being, you can continue to use Geeklog 1.6.1, which we will still support with security fixes until at least the release of 1.8. But by the end of this year, it's really high time to abandon PHP 4 ...

It's not exactly that I'm conservative. If it depended on me, I would have every one to upgrade all RHEL4/CentOS4 to RHEL5/CentOS5. My point is that many hosting services and companies *are* *stuck* to RHEL4/CentOS4 because life-cycle policies. For example: if somebody asked for a Linux server at Rackspace during (and after) 2007, they surely installed RHEL4 in the customers' servers.

With comercial hosting providers is not such a big issue, as anyone may switch to any other provider when needed. With corporate world is not that easy. They follow strict policies related to life cycles, which is the case of the sponsor/provider that hosts my website.

I'm not asking to support back PHP 4.3.9 (which, by the way, is actively patched-when-it-is-needed by Red Hat because it's the version used by RHEL4). I just want to say it would have been nice to take into consideration the significant number of Red Hat Enterprise Linux 4 and CentOS 4 servers which use PHP 4.3.9 that will not be able to use 1.7.0 because the requirement of PHP 4.4.0.

Polls are not the best way to know a market, they only give you an idea of what regular visitors think. I'm pretty sure lots of Geeklog users do not visit Geeklog.net on regular basis, and usually they go directly to download section to get security patches or releases, and I would bet a year of salary that most of those users never noticed that poll.

Something that should have to be taken under consideration to decide the minimal version of PHP4, is that until RHEL4/CentOS4 reach the end-of-life in february 2012 (seven years cycle), PHP-4.3.9/MySQL-4.1.22 *will* *be* *alive* *and* *kicking* (and maintained/patched by Red Hat).

The minimal requirement of PHP 4.4.0 is pointless if a big number of the open source servers that are tied to PHP4 use 4.3.9.

Again, it's not a big issue. All RHEL4/CentOS4 servers just will have to stay with 1.5.2/1.6.1. Just do not forget those servers will be alive and kicking until february 2012. On february 2012, PHP4 will truly die.

Installing PHP 4.3.9 as "new" in 2007 as part of a 5 year plan was idiotic. End of life for PHP4 was announced July 31, 2007. I don't see how anyone could make such a decision in good conscience.http://www.php.net/archive/2007.php#2007-07-13-1

CentOS is now leading the Linux distribution statistics on web servers with almost 30% of all Linux servers. So, please keep supporting PHP 5.1.x (CentOS 5). It would be great if Geeklog could support again PHP 4.3.9 (CentOS 4).

After the latest 5.1 update it became 5.2.0 and it all went from there. Right now the only actively developed versions are PHP 5.2.x and PHP 5.3.x (both considered stable).

So I can understand the development direction, why develop upon something that isn't supported anymore.
On top of that, the focus of Geeklog is security. There isn't anything secure about PHP versions that haven't been updated for 2 or 4 years (no security patches, nothing).