forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: multiple skin descriptors, skin versions
Date Fri, 30 Jan 2004 18:44:29 GMT
Quoting Marshall Roch <>:

> Dave Brondsema wrote:
> > I also want to have install-skin work to delete the existing skin, if
> > any, so it can be used to update skins also.  But that could be
> > dangerous if (for example) forrest-site was deleted and then there
> > was no .zip for it to replace it.
> Just download the skin before deleting the old one.  If it doesn't
> exist, obviously, don't delete the old one.  Or am I missing something?

Yeah I guess so.  I was concerned because we make the assumption that the has a foobar directory in it.  So an improper skin zip file
could be cause some problems, but that shouldn't have any affect on skins that
come with forrest.

> > Perhaps we could put all the skins in the default skin descriptor?
> > But how then would we keep the skins there up to date?
> I don't follow.  What are you trying to accomplish here?  

Nevermind.  My thoughts were thinking about solutions to the above issue, which
isn't really a problem.

> > I suppose we could do it manually each time we do a forrest release.
> > We do support versioned skins.
> I don't like this.  Skins should be able to be updated more often than
> the Forrest core.
> I think that for this to work, skins should have their own version
> numbers, unrelated to the version of Forrest they work with.  The reason
> for this is that some versions of Forrest will not need new versions of
> the skin, so updating the skin is pointlessly redundant. On the other
> hand, there will be browser/bug fixes, tweaks, additions, etc. in the
> skin which should warrant a new skin release, but not a new Forrest release.
> This scheme is based loosely on the PEAR (
> versioning scheme:
> 1) If modifications are needed to work with a new version of Forrest,
> give the skin a new major version number (1.0 to 2.0)
> 2) If BC is maintained between Forrest releases, do not create a new
> skin version.
> 3) Feature additions to the skin, provided that it maintains
> compatibility with all of the Forrest versions that it has previously
> worked with, should increment the minor version number (1.1.0 to 1.2.0)
> 4) Bug and browser-compatibility fixes that do not significantly modify
> the skin nor add new features should increment the patch version number
> (1.1.1 to 1.1.2)

This makes sense to me.  So the skin fetching target should get the highest
version compatible with the user's version of forrest.  So we would need to
track what version(s) of forrest a given skin version is compatible with.  For
example, skinabc 1.3 is the latest version compatible with 0.5, but there is
already a skinabc 2.0 which is compatible with 0.6-dev.  0.5 users shouldn't get
2.0 but 0.6-dev users should.

Should the standard skins that come with forrest be available seperately?  Use
case: we release forrest 0.6 and it comes with all the standard skins.  But
afterwards there are some fixes to forrest-site that we want to make available
to the public.  0.6 users could use the install-skin target to get the latest
forrest-site skin and we don't have to make a 0.6.1 release of forrest.

> > Speaking of which, the forrest version in is 0.5
> > but the description says 0.6-dev.  Shouldn't the version be 0.6-dev?
> > Would this adversely affect version specific .xmap and .xconf files?
> This is adversely affecting skins made for 0.6.  When I ran
> "package-skin" on xhtml-css, the filename was or
> something like that, even though it (apparently) doesn't work with 0.5.

Right.  Should it be 0.6 or 0.6-dev though?

Dave Brondsema - personal - programming - student org 

View raw message