Monday, January 25, 2010

Banshee Release Schedule

We are aligning Banshee's release schedule with GNOME's, at least for the next few months. Banshee 1.6 will be released the same day as GNOME 2.30, and we'll have three beta releases before then.
  • 1.5.3 - Jan 27 - Wednesday!
  • 1.5.4 - Feb 24
  • 1.5.5 - Mar 10 - String Freeze
  • 1.6.0 - Mar 31
I'm excited to try switching our schedule from feature and whim driven to time-based; I think it will be felt positively by everybody: contributors will know when their work will reach people, translators will have time to translate, and users can stop wondering what mixture of magic and bribes will cause a release to finally happen.

Subscribe to the Banshee development calendar, find out how to help test the latest Banshee, and/or contribute your creativity and sweat!


  1. only thing that's missing is a roadmap, so that we know what we can expect :)

  2. So according to the news an 1.5.1 was a stable release. And 1.5.2 a beta release. Kind of confusing.

    That being said, this is great news!

    Banshee 1.6 will very likely make the Ubuntu 10.4 Lucid release.

  3. This is great news. I love Banshee but it's random releases make it kinda hard to get excited about developments sometimes.

  4. @Anonymous: If we had a roadmap and tried to stick to it, that would basically be a feature-driven release process then. You can get a good idea of what will be in 1.6 by looking at the releases leading up to it and what branches and activity are happening in git.

    @Tim: yeah, that was unfortunate, and due largely to not having a time-based release schedule. We felt 1.5.1 was a big improvement over the 1.4 series, and distros are hesitant to ship it if it's not a 'stable' release. This schedule for 1.6 was proposed/adopted largely to avoid that confusion going forward.

  5. time-based schedule ftw! very good news, this will help getting banshee adopted as the default media player in distributions!

  6. @Michael: You have the same name as me and said pretty much the same thing I would have said... who do you think you are? ;)

    But yeah, I think a time-based schedule is a big step forward for Banshee and I really hope it works out well during this cycle.

  7. It took awhile to get everyone agree but well worth it!

  8. @Gabriel

    Looking at git and the "release leading up to" a new release are not good ways to get an idea about what to expect in a new release; at least not for average users like myself. I find it very confusing.

    Couldn't you have a roadmap that just said what people are working on for the next release and how likely it is to make the release? That would give us a better idea of what's in the pipe line. Plus, it makes me happy to have a feature to look forward to and I always enjoy reading about what's up next for Banshee.

  9. Hi,

    Time only releases are as bad as feature only releases, if not worst.

    What I mean by this is that if you have a deadline, you NEED to know whether what you are trying to code will be achievable... you don´t want to be coding something big and be "forced" to release it with lots of bugs just so that you don´t miss the deadline.

    So to be able to plan this you will need to have at least in your mind a breakdown of the most likely areas that you will want to concentrate on even if you don´t fuly commit to it in case there is no time to get it done... if nothing like this is done at all then the time only released are going to fail, miss the deadline or not be of enough quality so logically some sort of planning needs doing at least on the head/s of the developer/s...

    So in short, I think a small flexible "roadmap" of what is likely to get worked on (as suggested before) would be benefitial in planning the releases and help users see what is coming even if it doesn´t make it into a specific release and will help focus the development effort

    Thanks for your great work

  10. I´m the previous poster again :)

    Just in case it wasn´t clear, what I´m advocating is a mixed model between feature driven development and time release

  11. Yeah, but we don't develop in a vacuum. We use bugzilla, the mailing list, IRC, etc to discuss new features and roughly figure out when something might land. And we develop big/risky features in branches that we don't merge until they're ready. It might be useful to non-core people to have that written up/summarized in a Roadmap, but two downsides to that are 1) it takes time that we could be spending coding and 2) it might give people an unreasonable expectation about what will land when.

    That said, I can understand it's nice to have a sense of where the project is going without having to spend many hours keeping up. I'll see if anybody has ideas/time/desire to try to improve that, either by making a roadmap-like document, blogging more often, or something else.

  12. @Gabriel

    I'm the 1st anonymous poster who suggested the roadmap idea (the person who posted after me about the limitations of time-only releases is someone else.) Just wanted to say thank you for listening to our input and e-mailing the banshee-list. Even if the roadmap-idea never materializes, I appreciate that you are taking the idea seriously and didn't just respond with the common "it's open source and it's free; shut up" arguement. This is exactly what makes Banshee such a great software project!

  13. @Forest: Thanks for suggesting a roadmap; I have a feeling you're not the only user interested in reading this sort of thing. And the good news is, it's on its way to materialization right now!