Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Rockbox versions codenames ...

Re: Rockbox versions codenames ...

From: Fred <speed-up_at_fr.st>
Date: Wed, 5 Feb 2003 20:11:26 +0100

>I see little gain in having tree official branches
> There is a reason we choose to merge certain patches at certain points in
time.

The "unstable" would only be a testing release, which would allow users to
send feedback and say what they'd want to be changed, how the software
works, if it's mature enough to be integrated to the main RockBox source. I
love to live on the edge, and I'm sure I'm not alone. The average RockBox
user may not be able to patch and compile the source, or even doesn't have
time to do so, but this "new" build may require a specific name, as it'll be
the third available one.
I can understand you want more explicit names (the Debian names were just an
exemple ...) but I think it should be time to name the releases and give the
code evolution a structure.

> Why not be less cute and more explicit? Call them stable, testing and
unstable.
Stable for the official releases, Cvs for the direct-from-CVS compiled
sources and Patch for the unstable patched ones, would you agree with this ?

Making the patches available through the Patch build doesn't mean you have
to integrate it one day or another to the main source : it should be a
showroom, a feature-testing and a bug-tracking solution. The users should
say if they want the patch to be integrated to the source, what needs to be
changed until that, and what they're thinking of the rockbox' latest
patches. This would be quite usefull I think ... if you don't agree with me
you just have to say it, doesn't matter if my release should be public or
not, it's a private release at first intention :-D

I'd like to have users view on the situation ...

Fred
Received on 2003-02-05

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy