I agree completely. I'm in the technical category, and often find  
myself being confused as to what build is what. I think Adam makes a  
good point here that would benefit a great deal of the community  
using and testing Camino, and in turn help give better feedback on  
the project.

Brian

On Dec 11, 2006, at 3:51 PM, [EMAIL PROTECTED] wrote:

> If I can just expound on my last point -
>
> The Mozilla devs have chosen
> what I view as a fairly complicated terminology set with branch,  
> trunk, aviary,
> nightly, and more terms all being thrown around.
>
> Camino is a simple, lean
> browser for Mac users.  Macs are for people who want simple, well  
> designed
> software (amongst other things).  Camino doesn't need to publically  
> participate
> in this confusion.
>
> I move that the beta.caminobrwoser.org page stay up
> eternally with something like this on it:
>
> --
> The "branch" build of Camino
> is the latest release along with bug fixes, minor feature updates,  
> and blah
> blah blah... Click here to download
>
>
> The "trunk" build of Camino is the
> base for the next release of Camino.  While it may have signficant  
> features
> changes, it's less stable than the branch build. Blah blah... Click  
> here to
> download
>
> The "X" build ... explanation... download link
> --
>
> No need
> to get complex about it.
>
> Know who wants this? Users - even technical
> ones - who are comfortable evaluating a beta product that may have  
> some bugs
> but isn't interested in navigating the terminology.
>
> It might be catering
> to a less technical crowd, but it would be the user friendly thing  
> to do.
>
>
> Adam Scheinberg
>
> --- Camino List <[email protected] wrote:
> At 12:00
> PM -0800 12/11/06, [EMAIL PROTECTED] supposedly scribed:
>>
>>> Or
> use the branch builds, which have all of the Camino-specific
>>> improvements
> that are being developed for 1.1.  Since almost every
>>> Camino change at
> this point is being added to both the branch and the
>>> trunk, there's really
> no reason for most people to use trunk builds
>>> (unless they have a burning
> desire to see the Acid2 test passing).
>>> The entire point of the branch
> builds is to have a stable development
>>> platform.
>>>
>>> -Stuart
>>
>
>> Indeed, except there has been an issue of identifying which is a
>> branch
> build and which is a trunk build. My first assumption is that
>> we are talking
> about the "nightly" folder. For as long as I can
>> remember, all files to
> download are uniformly  called "Camino.dmg."
>> So one needs to rely on the
> folder name. I think it was only a month
>> or so ago when I last checked,
> I think 1 folder actually said "trunk"
>> in it's name.  Just checked and
> it seems a lot of folders have
>> "trunk" added. This is good.
>>
>> But
> CAN we assume that any folder that does NOT contain a trunk
>> release is
> a branch release? And, what version is contained in the
>> following folders,
> each one populated today?
>>
>> 2006-12-10-22-1.0-M1.8.0
>> latest-1.0-M1.8.0
>
>> 2006-12-11-02-1.1-M1.8
>> latest-1.1-M1.8
>>
>> While there MAY be clues,
> they don't make sense. Why would something
>> with yesterday's date be different
> from something when today's date
>> when both are generated today? Why would
> a "latest 1.0..." be posted
>> at the same time a "latest-1.1..." is posted?
> I see there's a ReadMe
>> from 2004 that obviously contains information that
> has NO elation to
>> what is being posted. Why can't a readme that actually
> tells us what
>> is what be posted into this directory? I can't imagine this
> would
>> pose some form of huge imposition to those who know and can post
> such
>> a file...
>> _______________________________________________
>> Camino
> mailing list
>> [email protected]
>> http://mozdev.org/mailman/listinfo/camino
>
>>
> _______________________________________________
> Camino mailing list
> [email protected]
> http://mozdev.org/mailman/listinfo/camino

_______________________________________________
Camino mailing list
[email protected]
http://mozdev.org/mailman/listinfo/camino

Reply via email to