Rockbox mail archive
Subject: Re: let's do a Rockbox v2.5 release
Re: let's do a Rockbox v2.5 release
It's like putting a stereo faceplate in a car on an assembly line and having
the dealer tell the customer that the radio won't play because they haven't
finished designing it yet. The code will run on an iRiver without playback
right now. You'd have to document that it won't work. It's far better to
release a build with all features intact and bug-free, especially since the
iRiver code will be more or less untested by the community.
If you really want to move forward on the release, I'd recommend branching
the code by yanking the iRiver stuff and stabilizing the functional pieces.
We also have to ask ourselves if RLOD, recording fixes, and the database are
worth the effort of freezing the code to iRiver development to get out an
official release. I'd recommend finishing iRiver and make a huge splash with
the next release. It's a good milestone and should garner a lot more press.
In the future, if you have something like RLOD and recording fixes, these
should be released as "dot-dot" builds instead of waiting a long time to get
the fixes into the public eye. Save stuff like id3 database and new platform
support for the big build numbers.
On 6/6/05, Linus Nielsen Feltzing <email@example.com> wrote:
> David McIntyre wrote:
> > Unless you're willing to branch code (bad idea in a project like this),
> > think leaving a BIG unfinished project like iRiver playback in the
> > for an official release is a bad idea.
> Why is that so?
Received on Mon Jun 6 22:01:13 2005
Page was last modified "Jan 10 2012" The Rockbox Crew