• foobar (9/9) Sep 08 2011 Recent threads discuss how D should incorporate a mechanism to version s...
• dsimcha (9/18) Sep 08 2011 language/tools.
• foobar (4/26) Sep 08 2011 Actually, I think you miss my point. See my reply to Vladimir.
• Vladimir Panteleev (15/29) Sep 08 2011 What happens when you want to use two libraries which require different ...
• foobar (4/41) Sep 08 2011 Since Phobos walks hand-in-hand with Druntime and the compiler it makes ...

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

dsimcha <dsimcha yahoo.com> writes:

== Quote from foobar (foo bar.com)'s article
 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.

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.

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

 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.
 
 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. 

"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

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.