Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@www.apache.org Received: (qmail 18786 invoked from network); 30 Jan 2004 18:52:32 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 30 Jan 2004 18:52:32 -0000 Received: (qmail 90860 invoked by uid 500); 30 Jan 2004 18:47:07 -0000 Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 90823 invoked by uid 500); 30 Jan 2004 18:47:07 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 90770 invoked from network); 30 Jan 2004 18:47:07 -0000 Received: from unknown (HELO delorean.solidusdesign.com) (65.42.175.122) by daedalus.apache.org with SMTP; 30 Jan 2004 18:47:07 -0000 Received: (qmail 11703 invoked from network); 30 Jan 2004 18:47:09 -0000 Received: from unknown (HELO localhost) (192.168.3.2) by 0 with SMTP; 30 Jan 2004 18:47:09 -0000 Received: from c-24-11-105-47.client.comcast.net (c-24-11-105-47.client.comcast.net [24.11.105.47]) by secure.solidusdesign.com (IMP) with HTTP for ; Fri, 30 Jan 2004 13:44:29 -0500 Message-ID: <1075488269.401aa60da34c7@secure.solidusdesign.com> Date: Fri, 30 Jan 2004 13:44:29 -0500 From: Dave Brondsema To: forrest-dev@xml.apache.org Subject: Re: multiple skin descriptors, skin versions References: <40197B4F.4030609@exclupen.com> In-Reply-To: <40197B4F.4030609@exclupen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 24.11.105.47 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on delorean.solidusdesign.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.60 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 foobar-version.zip 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 (http://pear.php.net) > 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 forrest.build.xml 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 xhtml-css-0.5.zip 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 dave@brondsema.net http://www.brondsema.net - personal http://www.splike.com - programming http://csx.calvin.edu - student org