Banshee 2.1: Small version increase, big change
With the fantastic 2.0 release behind it, the Banshee project announces changes for the future.
Dependencies, why do I care?
In a mailing list posting today Banshee Core developer Gabriel Burt announced the much anticipated dependency decision for the upcoming Banshee 2.1. For every release so far the policy for Banshee has been to support distributions going back roughly 1½ years: this is all about to change.
The reason naturally being the arrival of the GNOME3 stack and the .NET worlds new GTK#3 bindings which will hopefully soon see its first release. Rather than supporting the legacy (and known limited) GTK#2 bindings the decision to make a clean break, allowing the first major refresh of Banshee in years and simultaneously allowing Banshee to drop a lot of legacy code and workarounds.
Besides moving all of Banshee to GTK#3, the targets to be dropped include the old and unsupported iPod integration (which was replaced with the standardized libgpod bindngs in the 1.7/1.8 cycle by Alan McGovern and friends) and the old style HAL hardware backend (which was replaced with udev likewise during the 1.7/1.8 cycle).
What happens to older Linux releases, like my Lucid?
While Banshee’s range of PPA resources are likely to continue merely providing the dependencies, a new bundle of joy has been added to the family. Older Linux users are now granted 32 and 64 bit generic bundles of Banshee which will run on any older Linux distribution, while integrating with your systems GStreamer media support framework and theming.
All fantastic work done by silent yet deadly handsome (and camera shy) Luxembourgian Banshee Core maintainer Bertrand Lorentz. As something new these releases will for the first time be distributed from the GNOME servers rather than Banshee’s own domain.
Moar GNOME, less C plz!
Aside using the very latest GNOME technologies and cutting out legacy code with the ruthless efficiency known only to true code ninjas, Banshee is aiming to obsolete the remaining bits of C code.. what.. no C, why? The answer is simple, C code is an order of magnitude harder to work with, especially within a managed code project such as Banshee.
Unmanaged code such as C code makes the portability wins from .NET much harder to attain as is evident in the Windows editions lack of e.g. Ubuntu One Music Store or Amazon MP3 integration. With Banshee 2.1 all this code is going to be replaced with new .NET bindings for the underlying libraries, the way mother intended code to be used, and will bring equal functionality and increased stability to all platforms.
Google Summer of Code 2011?
Banshee is also participating in Google’s annual bonanza of code and glory, this year we have gotten the pleasure of working with student Tobias Arrskog who will be working on uPnP server and client integration under Banshee luminary Alexander Kojevnikov.
Tobias has already begun introducing himself to the community and getting used to the Banshee culture and you can all look forward to hearing more about his progress as GSoC progresses.