From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Thu, 3 Jun 2010 13:12:09 +1000

On 3 June 2010 06:07, Dominik Riebeling <dominik.riebeling_at_gmail.com> wrote:
> On Tue, Jun 1, 2010 at 1:03 PM, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
>> access?) I want to copy the current theme site and disable updates.
>> The reason to do this is because there is a script in
>> utils/skinupdater which (should) extract a given zip file, run the
>> update program over it and zip it back up so the entire theme site can
>> get updated in one hit. But if that happens no themes will work for
>> 3.6... so for a while it would great if we hosted 2 copies of the
>> theme site....
>
> So why make the theme site read only? IMO this is a good chance to add
> syntax version handling for themes. Basically, I'm thinking of
> something like this:
>
> - add a theme syntax version number to the build-info files retrieved
> by Rockbox Utility (and / or to rockbox-info.txt)
> - modify Rockbox Utility to send this version number to t.r.o when
> requesting the list of themes.
> - make t.r.o respect that version and return a different list of
> themes (and adjusted download locations). Depending on the checkwps
> results the version number could even get figured automatically during
> upload. checkwps would need to be able telling about the syntax
> version its checking against, but adding this functionality should be
> trivial.
>
> I see several advantages with this:
> - when the next incompatible change to the syntax comes up we only
> need to increment the version number. We had such changes a few times
> in the past already, especially when the parser became stricter
> (though that wasn't exactly tag changes).
> - we have proper handling for themes with different syntax. IMO this
> is much better than some workaround solution just for the current case
> (especially from a view of a tool that gets distributed). Besides,
> currently Rockbox Utility doesn't care about compatibility of themes.
> So if a theme runs with the current build but not the latest release
> Rockbox Utility won't notice the user about it and even install that
> theme, even if the installation is the latest release. This is
> something that needs to get fixed anyway. Instead of fiddling around
> with revision numbers a version number looks like a simple solution to
> me.
> - people can still access old themes (is there a reason to drop them?
> Disk space shouldn't be an issue I guess?). This also leaves the door
> open for people to pick up old themes and port them to the new syntax
> (obviously only an issue if there is no update tool). Or have themes
> around if they decide to run an older version of Rockbox for whatever
> reason.
> - eventually a tag could get introduced that holds the theme file
> version, so there would be a way for Rockbox itself to have a
> user-friendly notification of the user if a theme is incompatible.
>
> The drawback I see is that it is some work to do. But some work has to
> get done anyway :)
>
> Thoughts?
>
>
>  - Dominik
>

I agree that keeping the one theme site would obviously be the best
solution, but I really dont like the idea of adding a version to the
skins. I feel it is a waste to put the extra handling in when it isnt
catastrophic if an old theme tries to be loaded (unlike old plugins
which can crash the player.) Also a change which breaks backwards
compatibility *might* happen once a year (apart from when the parser
was made stricter I can only think of one other change which caused
these breaking issues.)
Another reason why theme version numbers is not helpful is lets say
the viewport tag is changed, if we bump the skin version then the site
will assume all themes will break but actually only ones which use
that tag would.

How about instead of working with skin version numbers we work with
svn revision numbers and store the checkwps revision of the last one a
theme passed in the database? rbtuil would then just send the build
rev (or release number, or date) and the themesite would filter and
themes that are newer and dont work out.

Jonathan
Received on 2010-06-03