On 2010-10-11 06:54, Jonathan M Davis wrote:
On Sunday 10 October 2010 21:26:28 Andrei Alexandrescu wrote:
I think it's a bit hasty to speak on behalf of all of Phobos'
participants. Phobos 2 is indeed different from Phobos 1 but
backward-incompatible changes to Phobos 2 are increasingly rare.
Sorry if I overstepped my bounds on that. It's just that from what I've seen,
the Phobos devs have been quite willing to make backwards incompatible changes
if they thought that they were an improvement, though they aren't done all that
frequently. Backwards compatability is considered, but improvements to the API
seem to override it.
Regardless, the result is that if you wrote your code for dmd 2.040 or something
similar and ended up trying to update it to 2.050, you'd likely have a number of
changes to make, though porting from Phobos 1 would be far worse. If Phobos were
completely stable or at least never made backwards-compatability breaking
changes, that wouldn't be the case. I fully expect that as Phobos matures, such
breaking changes will become quite rare if not outright nonexistent, but they do
still happen. Actually deprecating and replacing the modules that are intended
to be deprecated and replace will help a lot with that, but that obviously takes
time.
- Jonathan M Davis
I think it's time to separate the compiler, the language and phobos in
the releases. One idea is the use three numbers to indicate a release of
phobos, major, minor and build, like this: 2.4.3. Increment the build
number when a implementation detail is changed the doesn't change the
API. Increment the minor number when a backwards compatible API change
is made and increment the major number when a API change is made that
break backwards compatibility.
--
/Jacob Carlborg
