digitalmars.D - DMD needs branches
- Denton Cockburn (14/14) Apr 20 2007 With so many people calling for branches of D, is it not possible for so...
- Leandro Lucarella (13/17) Apr 20 2007 The problem is the D spec, wich changes as DMD changes. As far as D spec
- Dan (2/3) Apr 20 2007 Is the specification copyrighted so that you cannot reproduce it?
- Denton Cockburn (8/9) Apr 20 2007 agreed, and even if the stable GDC would say, "implements the D spec as
- Dan (2/16) Apr 20 2007 I agree with this system. Hey Walter, any chance we could get a stable ...
- Nicolas J. (7/21) Apr 21 2007 I htink that would be very unpractical. Creating a stable branch also me...
With so many people calling for branches of D, is it not possible for some to do it themselves? What prevents branching GDC at a supported level of DMD support, then using that branch mainly as a bug-fixing branch? I thought GDC was an implementation of the D spec. Are there libraries that GDC uses that can't be accessed? and even if that's so, it's more the language compiler and such that's the problem right? I'm new to D, just learning it now because it seems to be a very nice mix between C/C++/Java and the dynamic languages such as LISP/Python/Ruby/etc. I admit that the lack of stability, as much as seen as a feature to some, causes a lot of trouble for someone just learning. If there was a stable version to learn, then simply progress to learning the new features of the next version, that'd make it a bit easier. There are enough examples out there where this works, Python (2.4, 2.5, 2.6, etc. each well documented) and Java (1.5, 1.6, etc). Just my 2 cents.
Apr 20 2007
Denton Cockburn, el 20 de abril a las 13:28 me escribiste:With so many people calling for branches of D, is it not possible for some to do it themselves? What prevents branching GDC at a supported level of DMD support, then using that branch mainly as a bug-fixing branch? I thought GDC was an implementation of the D spec.The problem is the D spec, wich changes as DMD changes. As far as D spec and DMD is not well separated, it would be useless to do branches on _any_ compiler implementation. -- LUCA - Leandro Lucarella - Usando Debian GNU/Linux Sid - GNU Generation ------------------------------------------------------------------------ E-Mail / JID: luca lugmen.org.ar GPG Fingerprint: D9E1 4545 0F4B 7928 E82C 375D 4B02 0FE0 B08B 4FB2 GPG Key: gpg --keyserver pks.lugmen.org.ar --recv-keys B08B4FB2 ------------------------------------------------------------------------ RENUNCIO PARA IR A REZARLE A SAN CAYETANO -- Crónica TV
Apr 20 2007
Leandro Lucarella Wrote:The problem is the D spec, wich changes as DMD changes. As far as D specIs the specification copyrighted so that you cannot reproduce it?
Apr 20 2007
On Fri, 20 Apr 2007 14:13:13 -0400, Dan wrote:Is the specification copyrighted so that you cannot reproduce it?agreed, and even if the stable GDC would say, "implements the D spec as found at location Z dated XX/XX/2007", so it wouldn't even be copying it really. Thus anything added to the spec after that date wouldn't be implemented in said stable implementation. Maybe even if Walter would give his permission to someone he trusts to maintain this stable version, without any extra workload upon himself.
Apr 20 2007
Dan <murpsoft hotmail.com> Denton Cockburn Wrote:On Fri, 20 Apr 2007 14:13:13 -0400, Dan wrote:I agree with this system. Hey Walter, any chance we could get a stable thrown up on Digitalmars.com, or perhaps dsource.org?Is the specification copyrighted so that you cannot reproduce it?agreed, and even if the stable GDC would say, "implements the D spec as found at location Z dated XX/XX/2007", so it wouldn't even be copying it really. Thus anything added to the spec after that date wouldn't be implemented in said stable implementation. Maybe even if Walter would give his permission to someone he trusts to maintain this stable version, without any extra workload upon himself.
Apr 20 2007
Denton Cockburn Wrote:On Fri, 20 Apr 2007 14:13:13 -0400, Dan wrote:I htink that would be very unpractical. Creating a stable branch also means that the whole documentation must belong to this branch, i.e it must be duplicated. Which might indeed pose some licensing problems, if Walter doesn't do it himself. Now, I am not a specialist, but I tend to believe that if the original license is kept in the new branch, it is a non issue. The other problem that I can see is explained in the documentation of the Mercurial source code management software: some authors simply don't like the idea of branching, simply because they understandably fear that what starts as a branch ends with a fork of their project. They give the example of Guido van Rossum who didn't appreciate the forking of Stackless Python. I haven't looked at the Python license, though. It may allow this sort of thing while the D license prevents it. But forking can also be implicit, as all libraries being written for the stable branch, people may become reluctant to upgrading. D being a langugage which tends to evolve very quickly, the gap between the stable and dev branches can become enormous, even with regular merges of bugfixes, and people get even more reluctant to upgrading. When a new stable branch is finally released (after 8 months or a year, for instance), there is always the constraint of backward compatibility which can be heavy. Now, these are standard issues that all major languages face. They evolve by having a stable and a dev/cutting-edge branch, and when it gains momentum the major libraries are updated as well, to the benefit of everybody. PS: BTW, I've tried Mercurial and I find it a very interesting tool, which works fine and intuitively. It also packs some powerful features like the Mercurial queues, which are patch queues just like the Linux kernel maintainers use daily. I need to test more deeply, but it seems to me that it can perfectly replace a tool like ClearCase without problem.Is the specification copyrighted so that you cannot reproduce it?agreed, and even if the stable GDC would say, "implements the D spec as found at location Z dated XX/XX/2007", so it wouldn't even be copying it really. Thus anything added to the spec after that date wouldn't be implemented in said stable implementation. Maybe even if Walter would give his permission to someone he trusts to maintain this stable version, without any extra workload upon himself.
Apr 21 2007