Phing development update

A few months have passed since the last Phing development update, so it’s about time to discuss some of the recent changes.

Releases

Phing 2.15.0 (and two point releases to fix regressions) were released recently. More details can be found in the change log.

Version 2.16.0 is scheduled for December 2016.

GitHub Issues

A task that’s been on my list for far too long is the migration of the existing Trac tickets to GitHub Issues. After some trial-and-error, that migration is now complete. All open tickets have been migrated, existing tickets and milestones can’t be modified anymore, but can be accessed for historical purposes. At some point, the phing.info site will be redesigned as well.

Slack team

Phing now has its own Slack team! If you want to join, send an invite to mrook AT php DOT net. I’ve installed a bridge to link the existing #phing IRC channel on Freenode.

3.0 / 4.0

In the last update, I discussed some of the plans for Phing’s future. Version 3.0 was intended to be a serious refactoring of the code, introducing namespaces, other PHP 5.3+ features and porting some features/ideas that were committed on the old unstable-3.0 branch.

However, maintaining OSS projects takes a lot of time. Phing’s no different. The 2.x versions are still actively in use and require maintenance and updates as well. I’ve tried to keep the 3.0 branch roughly in sync with the changes that are going on in master. This means that 3.0 hasn’t progressed as fast as I’d like.

Meanwhile, PHP 5.5 reached end-of-life status last July. Phing 2.x still supports PHP 5.2+, a promise which is both becoming hard to keep and less and

With those things in mind, I proposed the following  list changes on Slack:

  • Start working on a “new” 3.0 branch (move the current 3.0 branch to 4.0 or -future)
  • Bump the PHP dependency to 5.6 or above
  • Start deprecating old tasks and code in the 2.x line (the old phpdoc and simpletest tasks, and other obsolete bits), remove that code from the new branch
  • Remove old wrapper / 5.2 compatibility code
  • Integrate SPL where feasible / necessary

Some of those tasks have been completed already, please take a look at the 3.0 branch for more details.

I’d like 3.0 to be mostly compatible with 2.x. There may be a few BC breaks, but existing – modern – build files should generally work. This way, a 3.0 release should be possible relatively soonish, ideally late 2016, early 2017!

Michiel Rook

Michiel Rook is an experienced, passionate & pragmatic freelance coach, developer & speaker from the Netherlands. He loves helping teams and companies to develop better software and significantly improve their delivery process. When he’s not thinking about continuous deployment, DevOps or event sourcing he enjoys music, cars, sports and movies.

Leave a Reply

Your email address will not be published. Required fields are marked *