John Dobbins wrote:
> For Post 1.0, why not follow the Linux model.
why? besides, this thread is 'towards mozilla 1.0' not 'beyond mozilla 1.0'
> Mozilla 1.0 would go into maintance mode, where 1.0.1 would only consist of bug
> fixes that proved to be stable in the development branch.
we have very little need for this. mozilla.org usually goes as far as a respin, if
someone else wants a branch w/ stability fixes they can do this.
> The next Milestone then would be 1.1.1
this is nice and counter intuitive wrt the current mozilla numbering scheme.
> with the odd second number showing that it's a new development branch.
this is rather useless. all of Mozilla is development. non development branches are
vendor branches (or milestone candidates).
> 1.1.2, 1.1.3, etc would follow until Mozilla org
> felt that it was ready to be released as Mozilla 1.2,
so we'd have a 1.1.1 but no 1.1.0 but we'd have a 1.2.0 ? yuck.
> replacing Mozilla 1.0.x as
> the stable version of Mozilla.
stable isn't really defined here and benefits no one in the real world. mozilla.org
currently makes releases which have been tested for a bit and continues developing.
If someone wants something else we encourage them to pick up a branded release.
> Then development would continue with Mozilla 1.3.1 as the next milestone on a
> new development branch.
still doesn't make any sense
> This would result in developers allways having a choice of two Mozillas,
developers usually have this choice already. latest milestone or trunk.
> a stable version in maintance mode,
I don't see why this is good. The reason linux and bsd have a maintenance mode is that
people are expected to get the latest patchlevel to a specific version. Browsers
don't really do this.
> for basing related projects on, and a developers version.
you can already do this w/ the current numbering system and people do (activestate,
beonex, netscape, ...)
In contrast, someone from some BSD group made a similar proposal which I was reminded
of in an earlier part of this thread when someone insisted we not ship 1.0 until we
reach 0 bugs. BSD's approach seemed to include invalidating non reproducible bugs in
an effort to reach 0. i still don't think you could reach 0 bugs in bugzilla even if
you took this approach. the best i can imagine is 0 open bugs filed before date X
against builds from date Y to date Z (Y<X<=Z)
Then we have the current numbering scheme, which almost works.
then we have a proposal from syd to rearrange the build system so that modules can be
tagged w/ LAST_KNOWN_GOOD or LAST_QA.
and then there are other project models.
Netbeans.org recently added a QA release marker to their versioning. they're called
Q-Builds and represent the most recent (twice monthly) build to pass a semi rigorous
inspection (probably akin to mozilla smoketests). This is actually sort of useful,
because it means netbeans visitors can get the last release (currently 3.2), the most
recent Q-build since 3.2 (currently 200106290100) or the last developer nightly
(currently 200107110100). If these numbers seem familiar, it's because netbeans
decided they liked the datestamp numbering scheme which mozilla.org also uses. -- To
some extent, the smoketesting which mozilla.org does and which is announced on
mozillazine is similar to Q-Builds, sometimes [EMAIL PROTECTED] implies that a previous
build would be better for people to use.
Netbeans aims to have 3-4 releases a year. which is rather different from mozilla's
releases every ~5weeks. But that is also a function of the state of the products. I
would and can use Forte (a netbeans derivative) for an extended period of time. Few
people would or could use Netscape6 for an extended period of time.
Also, the changes between netbeans releases are very big, often re-architecting entire
modules. This means that people have reason to stick with a version or series for a
given project (NetBeans is a Java IDE ... well it's also a Java Platform -- just as
mozilla has the am I a browser or am I a platform identity crisis).
With IDEs, your forms, projects, build settings, associations, keybindings (yes
netbeans does flexible keybindings already), and add ins are all likely to be affected
by a new release (mozilla plugin architecture hasn't broken compat. in a while,
netbeans add ins often require at least a rebuild -- sometimes the add ins have been
integrated into the main product ...). So if you're developing a java application with
Forte or NetBeans you really want to use it to get your work done and will only want
to update if there's a serious bug or a wonderful new feature.
With browsers, you have maybe 5 things which persist from session to session (history,
bookmarks, mail, cache, sidebars). Of these, history/sidebar/cache can be regenerated
(or discarded), and bookmarks/mail have rather stable formats. This means that it's
usually pretty safe (* you're still using developer software so no guarantees...) to
quit one browser version and install a slightly (2days-2weeks) newer one.
OpenOffice seems to do binary releases every 3-7 weeks, i think 632 relates to the
32nd week (probably since 10/13/00 when the 6.0 project began)...
I haven't found much info about their release cycle but i don't think that they intend
to use the linux or bsd schemes.
references:
Netbeans http://www.netbeans.org/
Download http://www.netbeans.org/project/www/downloads.html
Q-builds http://qa.netbeans.org/processes/q-builds-program.html
[where they discuss nearly everything] news://news.netbeans.org/netbeans.nbdev
Sun Forte http://www.forte.com/
OpenOffice http://www.openoffice.org/
syd posts are either irc://irc.mozilla.org/#mozilla or news://news.mozilla.org/
<-anywhere
ActiveState Komodo http://www.activestate.com/komodo/
Beonex Communicator http://www.beonex.com/
