www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - NIH syndrome and D

reply foobar <foo bar.com> writes:
Recent threads discuss how D should incorporate a mechanism to version
symbols/modules. 
E.g. std.xml[2], std.io vs. std.stdio and std.regex[p]. 
My question is WHY?

D *already* employes Git and there is no point in reimplementing it inside the
D language/tools.
I suggest this simple zero-implementation scheme [KISS!]:
use git tags to tag Phobos releases and advertise the decided upon version
scheme in the docs. Make sure to document APIs with the minimum required Phobos
release version [git tag!] and add a "Releases" web-page that documents API
changes. 
If someone needs a specific (older) version of e.g. std.xml he/she will simply
download the specific version of Phobos already available publicly online. 

PS
I think that std.stdio is not KISS and should be deprecated in favor of std.io
Sep 08 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from foobar (foo bar.com)'s article
 Recent threads discuss how D should incorporate a mechanism to version

 E.g. std.xml[2], std.io vs. std.stdio and std.regex[p].
 My question is WHY?
 D *already* employes Git and there is no point in reimplementing it inside the
D

 I suggest this simple zero-implementation scheme [KISS!]:
 use git tags to tag Phobos releases and advertise the decided upon version

release version [git tag!] and add a "Releases" web-page that documents API changes.
 If someone needs a specific (older) version of e.g. std.xml he/she will simply

You miss the point. The point isn't to make it **possible** to make old code work. It's to make it **automatic**.
 PS
 I think that std.stdio is not KISS and should be deprecated in favor of std.io

If that much of my code is broken, I will fork Phobos just out of spite.
Sep 08 2011
parent foobar <foo bar.com> writes:
dsimcha Wrote:

 == Quote from foobar (foo bar.com)'s article
 Recent threads discuss how D should incorporate a mechanism to version

 E.g. std.xml[2], std.io vs. std.stdio and std.regex[p].
 My question is WHY?
 D *already* employes Git and there is no point in reimplementing it inside the
D

 I suggest this simple zero-implementation scheme [KISS!]:
 use git tags to tag Phobos releases and advertise the decided upon version

release version [git tag!] and add a "Releases" web-page that documents API changes.
 If someone needs a specific (older) version of e.g. std.xml he/she will simply

You miss the point. The point isn't to make it **possible** to make old code work. It's to make it **automatic**.
 PS
 I think that std.stdio is not KISS and should be deprecated in favor of std.io

If that much of my code is broken, I will fork Phobos just out of spite.

Actually, I think you miss my point. See my reply to Vladimir. Regarding making old code work automatically - Per Walter's POV, if you do not intend to maintain the code than you can download the exact release of D used to create your application. This is why old versions of DMD are made available online. You cannot realistically expect to compile your old code written for an ancient release of DMD/Phobos and have it work exactly as before using latest DMD. You can either download the release of DMD & Phobos that matches your code or update it to the newer DMD/Phobos. As long as Phobos is tied to a specific version of DMD, it should have the same release tag as DMD. This is simply a matter of Phobos release policy. It *should* have a release policy unless we want to specify git commit hashes on the master branch.
Sep 08 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 08 Sep 2011 20:58:53 +0300, foobar <foo bar.com> wrote:

 Recent threads discuss how D should incorporate a mechanism to version  
 symbols/modules.
 E.g. std.xml[2], std.io vs. std.stdio and std.regex[p].
 My question is WHY?

 D *already* employes Git and there is no point in reimplementing it  
 inside the D language/tools.
 I suggest this simple zero-implementation scheme [KISS!]:
 use git tags to tag Phobos releases and advertise the decided upon  
 version scheme in the docs. Make sure to document APIs with the minimum  
 required Phobos release version [git tag!] and add a "Releases" web-page  
 that documents API changes.
 If someone needs a specific (older) version of e.g. std.xml he/she will  
 simply download the specific version of Phobos already available  
 publicly online.

What happens when you want to use two libraries which require different incompatible versions of the same module? How do you suggest to tag every book/article/etc. with a module/Phobos version to use? Moreso: Phobos pretty much walks hand-in-hand with Druntime and the compiler. You'll find that it won't be easy to make today's Phobos version work with DMD from two compiler versions ago. There's also the inter-dependencies between Phobos modules themselves. Your advice could simply be extended to "if you don't want your code to break when updating D, don't update D". -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Sep 08 2011
parent foobar <foo bar.com> writes:
Vladimir Panteleev Wrote:

 On Thu, 08 Sep 2011 20:58:53 +0300, foobar <foo bar.com> wrote:
 
 Recent threads discuss how D should incorporate a mechanism to version  
 symbols/modules.
 E.g. std.xml[2], std.io vs. std.stdio and std.regex[p].
 My question is WHY?

 D *already* employes Git and there is no point in reimplementing it  
 inside the D language/tools.
 I suggest this simple zero-implementation scheme [KISS!]:
 use git tags to tag Phobos releases and advertise the decided upon  
 version scheme in the docs. Make sure to document APIs with the minimum  
 required Phobos release version [git tag!] and add a "Releases" web-page  
 that documents API changes.
 If someone needs a specific (older) version of e.g. std.xml he/she will  
 simply download the specific version of Phobos already available  
 publicly online.

What happens when you want to use two libraries which require different incompatible versions of the same module? How do you suggest to tag every book/article/etc. with a module/Phobos version to use? Moreso: Phobos pretty much walks hand-in-hand with Druntime and the compiler. You'll find that it won't be easy to make today's Phobos version work with DMD from two compiler versions ago. There's also the inter-dependencies between Phobos modules themselves. Your advice could simply be extended to "if you don't want your code to break when updating D, don't update D". -- Best regards, Vladimir mailto:vladimir thecybershadow.net

Since Phobos walks hand-in-hand with Druntime and the compiler it makes even more sense to tie them together with the _same_ version number. You are correct in that if you depend on an old deprecated version of D, you shouldn't expect to update D to a newer incompatible version and expect your code to work without any changes. This is completely orthogonal to the question of which mechanism is used for release management. Corollary: How do you suggest to tag every book/article/etc. Which module name(s) would you employ? xml vs. xml2? stdio vs. io? Breaking API changes should be minimized regardless of mechanism employed.
Sep 08 2011