dsimcha Wrote: > == Quote from foobar ([email protected])'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.
