[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2022-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-09-06 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-09-06 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-08-23 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

--- Comment #4 from Jonathan M Davis  ---
(In reply to ZombineDev from comment #3)
> I agree that it's quite annoying. Perhaps we can add another predefined
> constant like __IS_DEV_VERSION__ which would evaluate to true iff the
> ddmd.globals.global._version has any non-digit character after the minor
> version (or simply if its length is > 8)?

The problem with that is that then you're testing specifically for dmd master
not that the code is newer than a particular release. If a change is made in
dmd master that's going to go in the next release, and __VERSION__ in dmd
master is the version of the next release, then you can check __VERSION__, and
the code will continue to do the right thing once dmd master becomes the next
release, but if you're checking __IS_DEV_VERSION__, then that doesn't work.
You'd have to change your code to use __VERSION__ once the next release is out.

While I can understand that with however the version numbers are currently
being generated, there may be issues having __VERSION__ be the number of the
next release in master rather than the current reelase, I really think that if
you consider what __VERSION__ is for, it really doesn't make sense for it to
give the same number as the most recent release for master. That destroys its
ability to be used for what it's designed for when dmd master is involved.

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-08-23 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

--- Comment #3 from ZombineDev  ---
I agree that it's quite annoying. Perhaps we can add another predefined
constant like __IS_DEV_VERSION__ which would evaluate to true iff the
ddmd.globals.global._version has any non-digit character after the minor
version (or simply if its length is > 8)?

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-08-23 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

--- Comment #2 from Jonathan M Davis  ---
(In reply to ZombineDev from comment #1)
> This was changed in https://github.com/dlang/dmd/pull/6935.

Drat. Well, I can't say that I understand how all of that stuff with the
release process works and how dmd knows what its version is, but the fact that
__VERSION__ for master is not a higher number than the latest release is a
definite problem for any code that needs to do something differently with
master due to upcoming changes or whatnot. I ran into this problem recently
when making some changes to vibe.d.

--


[Issue 17775] dmd master __VERSION__ should match the major release that it will be for

2017-08-23 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17775

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #1 from ZombineDev  ---
This was changed in https://github.com/dlang/dmd/pull/6935.

--