The Bi-Track Proposal (was Re: Unrant)
giovanni.giorgi at siforge.org
Fri Dec 17 08:39:27 UTC 2004
Michael Latta ha scritto in data 17/12/2004 1.39:
> I am not arguing against backward compatibility (though there is a
> cost in that as the Java community is learning). What I am saying is
> that when a new JDK is released it is not coupled to the release of
> NetBeans, or Eclipse, or even JWSDP. Someone focused on Web
This is true. The fact is that a commecial product (like JDK or
M$-Windows) should be "quite" back compatible with at least its previous
We should take care of this, to encourage developers!
For example JEdit and Eclipse changed they Plug-InAPI about 2/3 time,
and this require a very active community.
Older plugin gets unusable!
On thge other side Perl 5 tries to be a lot nice with old perl code, and
Perl 6 will sacrifice only the minimum compatibility.
PHP porting from v2 to v3 or v4 is known to be a nightmare, because they
changed the SCOPE of the variables :)
> [...]For Squeak decoupling the core release schedule from package
> release schedules would allow the package maintainers to work at their
> own pace.
I completely agree. This could be the goal, the essence of the "Base
Squeak Image": fast as a rabbit :)
Then we can have a "Rock Solid" released about every two or four base
It will have the same version number but the "RS" after.
Squeak 4.1 (base)
Squeak 4.2 RS
Squeak 4.3 (base)
Squeak 4.4 (base) <--- Example of delayed Rock Solid release
Squeak 4.5 RS
This would mirror the Linus way of organizing the Linux Kernel.
(Note: will not have two release with the SAME number, to avoid confusion)
The RS'd have: a Release notes Workspace and some nice stuff for
developing already installed.
The base image'd be "naked" and only for developers: they can choose
they tools to configure it.
Giovanni Giorgi http://www.squeak.org
More information about the Squeak-dev