forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: multiple skin descriptors, skin versions
Date Wed, 04 Feb 2004 15:45:15 GMT
Quoting Nicola Ken Barozzi <nicolaken@apache.org>:

> Dave Brondsema wrote:
> > Quoting Marshall Roch <marshall@exclupen.com>:
> > 
> >>Dave Brondsema wrote:
> >>
> >>>>IIRC I had added a filename convention too, so a skin would be for
> >>
> >>example:
> >>
> >>>> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
> >>>
> >>>I like this.  Simpler is better.
> 
> 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)
> 

No, we don't always want to get a skin with the highest number.  When forrest
0.4, 0.5, and 0.6-dev users update a skin, it is quite likely that they will
download different files and only the 0.6-dev user will download the one with
the highest version number.

If a skin is released as skinname-f0.5.zip 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 skinname-f0.5.zip, especially because
that makes it difficult to know that is has been updated.

> >>I thought this was the problem.  Skin version 0.3 might still work for 
> >>Forrest 0.6 and 0.7, but with your proposed naming scheme, each skin 
> >>would have to be re-released for each Forrest release, and bug fixes to 
> >>the skin release for 0.6 would not be applied to the release for Forrest 
> >>0.5.
> > If skin version 0.3 is compatible Forrest 0.5 and still works when 0.6 and
> 0.7
> > are released, we could keep skinname-f0.5-0.3.jar  The fetcher could get
> the
> > skin with the highest forrest version number possible (less than or equal
> to the
> > version of forrest installed, of course).
> 
> 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.

> 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 skinname-skinversioncompat.zip
>     - 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 skinname.zip (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).

> 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 
> version.
> 
> WDYT?
> 
> I hope I was clearer this time :-)
> 

I think we're making progress ...


-- 
Dave Brondsema 
dave@brondsema.net 
http://www.brondsema.net - personal 
http://www.splike.com - programming 
http://csx.calvin.edu - student org 

Mime
View raw message