forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: multiple skin descriptors, skin versions
Date Wed, 04 Feb 2004 19:09:44 GMT
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <>:
>>skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
>>Yes... err... but in my mail I also proposed that maybe the '0.3' part 
>>is not needed. The rationals was that a skin has to be gotten with the 
>>highest number anyway, so we can go without it altogether and simply use 
>>the publish date of the file.
>>  hence: skinname-f0.5.jar (read on)
> If a skin is released as and then significant enhancements are
> made and a new release (still forrest 0.5 compatible) is made, what should it be
> called?  I don't think it should still be, especially because
> that makes it difficult to know that is has been updated.

I tend to think that the file date is a good enough indication... read on...

>>But we don't know still if they are compatible. Hence my subsequent 
>>proposal that instead of f0.5 we use the *skin contract* version, that 
>>is separate from the Forrest version. We should change it when the skins 
>>have to change.
>>   hence: skinname-0.2.jar where 0.2 is the *skin contract* version
> What exactly do you mean by *skin contract* version?  0.2 means what?  If I saw
> a file named like that, I would assume that it is version 0.2 of the skin,


> and I
> have no idea what versions of forrest it is compatible with.

Hmmm... conceded as well :-)

>>In essence, what should happen is:
>>  - if a skin is not present
>>    - get the skins descriptor
>>    - get the download dir of the skin
>>    - get the current forrest skin version compat
>>      (in the current Forrest)
>>    - look for a file named
>>    - if found
>>      - download and unpack skin
>>      - add a file with the date of the zip and the version
>>        in the skin
>>    - if not found
>>      - search for (best effort skin)
>>      - if found
>>        (do as already specified above)
>>To update the skins, it does as above but downloads the skin only if the 
>>remote file date is newer than the date that it wrote inside the skin.
> I don't think we should rely on remote file dates.  It is meta-data that is
> easily lost or changed (e.g. uploading the same file again: the file gets a new
> date and the original date is lost).

Well, it's possible to change it, but again, I concede that this is what 
would generally happen.

>>In this way we don't need to generate and maintain descriptors in the 
>>download dirs and in the zips, and have a simple naming scheme.
>>This is what I meant about Mozilla: the skins are downloadable per major 
>>Mozilla version, not per skin version. In our case it would be per skin 
>>I hope I was clearer this time :-)
> I think we're making progress ...

Well, from all this the summary seems to be:

1 - we need indications about forrest and skin compatibility in robust
     metadata (filename is the current best guess)

2 - the compatibility version should indicate the nearest Forrest
     version to which it's compatible (nothing said though for forward
     or backward compat, it's Forrest that should know)

3 - we need to keep the information available also in the deployed state
     so to be able to check the repositories for new versions.

All this means one thing to me: we need a tool for it as Ant does not 
cut it. In the Incubator we are incubating Apache Depot, that contains 
Ruper to download artifacts from repositories, query them, and a tool 
called Version that Ruper uses with which we can define our special 
versioning scheme.

Here are the old sites of Ruper and Version (ATM SF seems down):


(IMHO we should slate this for 0.7, disable downloaded skin support, and 
finish things for a 0.6 release)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message