On Tue, Jan 16, 2001 at 11:04:57AM -0800, Brendan Eich wrote:
> > *yes*: don't sweat it. forcing implementers to freeze interfaces once the
> > magic ship-date has arrived, and then to support both old interfaces and any
> > new ones added later ... is one of the worst lies perpetrated by
> > Booch/Grady/Gamma/etc...
>
> You make a good point. Others quail about the OLE1/2/3 compatibility
> nightmares. We shouldn't worship compatibility over all other goods,
> and if some interface isn't freeze-worthy, it'll be left out of the set
> of blessed Mozilla APIs.
>
> However, we aim to have such a set, because developers can't afford to
> "port" to every new release of "Mozilla system libraries" -- some of
> which may come from downstream distros (RedHat, let's say) in their own
> good time. For sure, libraries must have version numbers in their names
> on systems where that's the convention, so multiple versions can
> coexist. But we'd like a common set of APIs in recent, if not all,
> versions to be consistent and frozen.
>
The solution to me seems very simple: Mozilla 1.0 arrives. CVS is forked.
Bugfixes (bugs, not enhancements) go into CVS. Real development goes into
the forked 1.1 tree. As a result, the 1.0 APIs remain nice and stable.
You develop against mozilla? Write against a stable version. When the new
version comes out, read the documentation describing how the APIs have
morphed, and port your code accordingly. You still have to port your code
and play catch up, but at least it's not a moving target.
This method has its plusses and minuses. But it's one that's been proven for
a lot of large projects:
- the Gtk/GNOME development suite (it's generally accepted that you program
against the release library suite, and port when the next one comes out)
- Python (i've got 3 versions installed now)
- the kernel itself (not just linux, but every major kernel)
That way, an application developer can say "I work with mozilla 1.0" and
expect mozilla1.0 to be installed (right alongside the spiffy new 1.1 with
the funky features that people may actually use for browsing).
I *don't* know how this translates for mozilla to pre-release versions. In
the Linux case, the stable/unstable minor version progression started well
before 1.0. But I would argue for mozilla that as long as we're pre-1.0 the
APIs should be flexible (a boon to John and all the other developers) and
any of us who are dumb enough to develop against it shouldn't be surprised
if we're playing catch-up :).
ari
PS one minor point: are C++ default values permitted in the mozilla coding
rules? if they are, i would hope that API changes would use them and
therefore keep the default behaviour equivalent to previous versions, as far
as possible... at the very least, if an API changes, the person committing
the changes should note the new blessed usage in the commitlog (with
lightning bolts and boils from on high for those who don't log
appropriately)
