Timestamping as a solution to versioning hell

[KnightMare]

On Wednesday, 15 May 2019 at 09:14:39 UTC, Alex wrote:

> Time stamping solves all these problems.

> With time stamping, we just have to remember which was the last 
> day our program worked(which we can guess, use a search, or 
> just look at a time stamp on the exe or source code).

I agree in main point: Dlang/Libs should be versioned with using 
timestamp(optional) as project/compiler/dub.

RT will change. Compiler will change. Too difficult store all 
versions and changes in one EXE/TAR/ZIP, better use last version 
only and store links to known GITs servers from where it can be 
restored.

Next I will talk about compilers not DUB (I dont use it so dont 
know it). Compiler and DUB can spawn some another CLI-tool for 
restore RT/compiler from GITs.

- Dlang distro comes with only last version of Phobos(or other 
name of RT).
- Modules (should change compiler) are versioned by 
Major[.Minor[ExperimentalOrAlphaBetaLetter "abcde.."]] - brackets 
means "optional" - 2.11f
import std.xml:2.0 : someFuncsList;
We can (public) import previous version with disable something 
old or replaced:
public import std.xml:1.8 : disable A,B,c,d(XmlDocument); // for 
concrete implementation of one implementation not all of it.
Or we can write new one from scratch.
Lettered-versions used explicitly only. Or when we asked "2.0" 
but 2.0 doesnt exists and RT contains 2.0e for example. 
Lattered-version can change in future (will some bugs in 
compilations steps but developer takes such risks). And 
Unlettered-version allow not to modify code for future when 
release 2.0 comes.
TODO I dont remember version for aug-2017, I can setup version by 
date std:xml:20170805 (YYYYMMDD where month/day is optional) 
(some online DB or just list of GIT tags will enough?).
- All older versions are stored at GITs servers (for better 
accessibility lets say in 6 continents). GIT stores tagged 
versions. When project/compiler see some fixed date or specific 
version that doesnt exists in current installation it downloads 
its from one of GITs to some known place (for searching 
source/libs).
TODO compiler can changed too. how to store it: as exe (password 
leaks can allow malware such EXEs) or as source with compilation 
possibility?
- DUB/project files contains freezed/fixed date (created with 
"today".init and can be updated manually or interactivelly for 
current/specific date).
Usually u import modules without any version (I am lazy too) 
means "use current/last one for fixed date".
TODO what about compiler name (DMD/LDC/GDC/someNew) and version? 
how to store it in bin folder? dmd.2.086.0.exe?

Well, I cant to see all use-cases now and many questions will 
raise but IMO versioning allow compile D-code after decades 
without headache.
Versioning is required feature.
"experimental" named modules shouldn't be used like moveton. Coz 
renaming module names in written source is ugly case.

Such versioning (as described above) allow
- to forget name/version hells.
- to use same names for future/new releases.
- to re/store all versions in some known place (GITs).
- to compile any sample from github/book after any changes in 
compiler/RT/modules.
- other many benefits.

Those who do not remember their past are condemned to repeat 
their mistakes. (c) dontRememberAuthor