[Jslib] Re: jslibs versions for product version?

[Eric Plaster]

Too bad we all live in different parts of the contry.  This would be a 
good white board / bar room discussion!

Pete Collins wrote:

> I believe originally we were talking about cutting a branch to 
> coordinate w/ mozilla and I guess Netscape releases.
>
> As far as local I/O goes now would be the time. 

I agree, it's the most solid.

>
>
> I am certain there is lots of broken and unfinished code.
>
> jslib at this stage of the game is very early in it's development.
>
> We all know it is slowly evolving, on need to fix development cycles.
>
> The only code that is well tested and worthy of being actual library 
> code is the I/O stuff because it has received the most attention.
>
> Ideally it all needs to happen. xpi's for each release of mozilla and 
> Netscape. Smart install scripts that can install the correct version 
> of the library etc . .
>
> I think we need module ownership here. I've only been focusing on the 
> I/O stuff. I plan on revamping that module after the nsIFile freeze. 

I can take the RDF and/or XUL modules.  They are small now, but have the 
most potential for growing.

>
>
> How about we clean up and test what is here now and cut a branch 
> target for mozilla 0.9.3 and Netscape 6.1? 

Sounds good to me.

>
>
> --pete
>
>
>
>
> Eric Plaster wrote:
>
>>
>> Ya, I agree.  We need to be producing milestones along with mozillas 
>> (and netscapes).  That way when we release a product (like I will be 
>> in a short while) we can say, "You need version 1.2 of JSLIB".  Then 
>> we should have a chart on our web site that corilates with the 
>> mozilla milestones.  For example:
>>
>> Mozilla Version
>> Jslib Version
>> 0.9.1
>> 0.1 <jslib-0.1.xpi>
>> 0.9.2 (netscape 6.1)
>> 0.2 <jslib-0.2.xpi>
>> 0.9.3
>> <jslib-0.3.xpi> 0.3 <jslib-0.3.xpi>
>> Latest
>> current <jslib-current.xpi>
>>
>>
>> This way, people know what version of jslib they should be using for 
>> there version of mozilla (or netscape).
>>
>> For the latest, we could have cvs automaticly create the xpi so that 
>> they can download the latest.  This would also mean that we can't 
>> break the tree.  You know, create a branch, make your changes, merge 
>> when you get the peer review ok.
>>
>> We should also tag the tree at different releases so we can recreate 
>> the xpi if necessary!
>>
>> -eric
>>
>> Martin T. Kutschker wrote:
>>
>>> Hi!
>>>
>>> What does that mean? Well, jslib is evolving with Mozilla. This is 
>>> good, but
>>> makes me wonder if the newest version of jslib runs (even partially) 
>>> on say
>>> Mozilla 0.9.1. This is not a real problem but annoying since Mozilla 
>>> is not
>>> a finished product. Eg I don't think I will rely on a jslib jar-file 
>>> for
>>> mozcalc as long as jslib changes (or seems to be changing) with the
>>> nighties. But I only work with/for milestones and rarely use or test
>>> nighties.
>>>
>>> OTOH, Netscape released two browsers 6.0 (now even XUL incompatible) 
>>> and 6.1
>>> (which certainly become XUL incompatible looking at the plans for 
>>> XUL). Both
>>> browsers are IMHO rather early releases but are promoted by Netscape.
>>>
>>> Should we focus only on Mozilla or keep the Netscape releases in 
>>> mind? I
>>> would love to write (little) apps using the power of Mozilla, but 
>>> would hate
>>> to ask all my users to use the latest milestone or even nighty to 
>>> get things
>>> right.
>>>
>>> IMH
>>> O it's time for a branch as the nsIFile API is about to change but 
>>> 6.1 is
>>> already released. Best way would be to check our own API (what is 
>>> there,
>>> what is ok/odd, what is missing). Then freeze the API, make the 
>>> branch and
>>> document any remaining issues for the NS6.1 branch (is a branch for 6.0
>>> worth any hassle?) like troubles with append.
>>>
>>> Any comments?
>>>
>>> Masi
>>>
>>