backporting features to D1

[Leandro Lucarella]

Walter Bright, el 16 de octubre a las 14:37 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 11 de octubre a las 12:51 me escribiste:
> >>Bill Baxter wrote:
> >>>But features that have
> >>>been tested in D2 and which are backwards compatible with D1?  Why
> >>>would anyone be against those?
> >>Because then you lose the definition of what is D 1.0. I believe there is considerable value not only in a stable compiler, but a stable language 
> >>definition.
> >What's wrong with calling this new language D 1.1 for example?
> 
> Nothing except I don't have a staff of hundreds to test and maintain 3 versions of D.

First, the timeline you have to maintain 3 version should be small. In
little time D 1.0 should be freezed and only 1.1 should be supported
(until 1.2 is released at least ;)

Second, you shouldn't have to maintain it yourself. I know this is a big
issue when your backend is closed source. If the "reference"
implementation of D would be opensource, I'm sure you will not have this
issue.

Again, see Python for example, it evolves really fast and is very stable.
I think they only maintain the latest version, except for secutiry fixes.

> >Again, did you ever saw how Python evolves? Really, it's really good.
> 
> No, I haven't looked at it.

Please do.

I'm not an expert on it, but here is a short (an maybe inacurate) resume:

Python major versions are very rarely released (2.0 was released arround
2001 and 3.0 will be released this year). This is because minor versions
are allowed to make small incremental backward incompatible changes, so
major versions are only done when the internal Python interpreter changes
drastically.

They way Python introduces new feature (even backward incompatible ones)
into a "stable" version (minor version is changed in this cases) is by
using a "future compatiblity" scheme.

For example, when the 'with'[1] statement were introduced (this was
a backward incopatible change because 'with' became a reserved word, so
old programs that used 'with' as a symbol had to be updated), you only
could use it throw a "future" statement:
from __future__ import with_statement

This was introduced in Python 2.5. So any program that worked on Python
2.4, works on Python 2.5 without modifications, even when Python 2.5 have
a new *backward incompatible* feature. Programs authors have a chance to
test the new feature and update their programs for a full minor version
timeline (minor versions are release every 2 years aprox., so you have
about 2 years to update and test your program).

Even more, in Python 2.5, programs using "with" as a symbol will get
a warning from the interpreter, so it's very hard to "forget" tu update
your program.

In Python 2.6 the 'with' statement is enabled by default.

All this extensions are managed through PEPs (Python Enhancement
Proposals), which are made and discussed by the comunity and developers.


This model works *extremely* well.

[1] http://www.python.org/dev/peps/pep-0343/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Forgive your enemies, but never forget their names