• Kai Nacke (17/17) Apr 16 2015 Hi all!
• Suliman (5/5) Apr 17 2015 It's better to start with 1.0
• Elie Morisse (6/8) Apr 17 2015 Too early, and it shouldn't be merged as a whole. The bulk of
• David Nadlinger via digitalmars-d-ldc (4/11) Apr 17 2015 In any case, please do let us know if we can do something to make your
• Jacob Carlborg (5/19) Apr 17 2015 Are there any plans on how the versioning scheme should look like? I.e.
• Dicebot (4/21) Apr 17 2015 What is the point in 0.99? It is not like version numbers in
• Dmitri Makarov (11/28) Apr 17 2015 The LDC developers should set criteria for what they consider to
• David Nadlinger via digitalmars-d-ldc (12/21) Apr 17 2015 This is not a hard and fast rule. Some counterexamples that come to my
• Jacob Carlborg (5/10) Apr 18 2015 You decide which platforms are officially supported. Failing tests on
• Andrea Fontana (3/4) Apr 21 2015 On Linux x86/x86-64 :)
• Kai Nacke (6/10) Apr 21 2015 The missing __mulodi4 symbol? I you need to link against
• Dicebot (5/9) Apr 21 2015 LDC should work now at least for Arch Linux @ ARM (it worked last
• bearophile (5/6) Apr 18 2015 I suggest to go to "1.0" when you feel ready.
• "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/15) Apr 19 2015 I don't think it matters much except for in a press release. So

"Kai Nacke" <kai redstar.de> writes:

Hi all!

The major D compilers are currently:

     dmd 2.067
     gdc 4.8.4
     ldc 0.15.1

Looks like ldc is still in its early stages. Given the fact that 
ldc is more then 10 years old (see David's presentation at 
DConf'13) then this does not really reflect the state of ldc.

I like to do something about the version number. Possible plans I 
identified are:

- The 2.067 merge gets version 0.99.0 and with the 2.068 move on 
to 1.0.0.
   (First version with D code in the frontend!)

- Just drop 0. Next version is 16.0

Any opinions or better ideas?

Regards,
Kai

"Suliman" <evermind live.ru> writes:

It's better to start with 1.0

jump from 0.16 to 16 is very strange. 1.0 mean ready for 
usage/production.

Also do you have plans to merge with 
https://github.com/Syniurge/Calypso ?

"Elie Morisse" <syniurge gmail.com> writes:

On Friday, 17 April 2015 at 07:42:49 UTC, Suliman wrote:
 Also do you have plans to merge with 
 https://github.com/Syniurge/Calypso ?

Too early, and it shouldn't be merged as a whole. The bulk of 
Calypso
should be split from LDC as a shared library and then I'll submit
PRs for the hooks and small changes to DMD and LDC needed by
Calypso.

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

On 04/17/2015 10:04 PM, Elie Morisse via digitalmars-d-ldc wrote:
 On Friday, 17 April 2015 at 07:42:49 UTC, Suliman wrote:
 Also do you have plans to merge with
 https://github.com/Syniurge/Calypso ?

 Too early, and it shouldn't be merged as a whole. The bulk of Calypso
 should be split from LDC as a shared library and then I'll submit
 PRs for the hooks and small changes to DMD and LDC needed by
 Calypso.

In any case, please do let us know if we can do something to make your 
life easier.

  — David

Jacob Carlborg <doob me.com> writes:

On 2015-04-17 07:19, Kai Nacke wrote:
 Hi all!

 The major D compilers are currently:

      dmd 2.067
      gdc 4.8.4
      ldc 0.15.1

 Looks like ldc is still in its early stages. Given the fact that ldc is
 more then 10 years old (see David's presentation at DConf'13) then this
 does not really reflect the state of ldc.

 I like to do something about the version number. Possible plans I
 identified are:

 - The 2.067 merge gets version 0.99.0 and with the 2.068 move on to 1.0.0.
    (First version with D code in the frontend!)

 - Just drop 0. Next version is 16.0

 Any opinions or better ideas?

Are there any plans on how the versioning scheme should look like? I.e. 
how and when a version number is incremented.

-- 
/Jacob Carlborg

"Dicebot" <public dicebot.lv> writes:

On Friday, 17 April 2015 at 05:19:05 UTC, Kai Nacke wrote:
 Hi all!

 The major D compilers are currently:

     dmd 2.067
     gdc 4.8.4
     ldc 0.15.1

 Looks like ldc is still in its early stages. Given the fact 
 that ldc is more then 10 years old (see David's presentation at 
 DConf'13) then this does not really reflect the state of ldc.

 I like to do something about the version number. Possible plans 
 I identified are:

 - The 2.067 merge gets version 0.99.0 and with the 2.068 move 
 on to 1.0.0.
   (First version with D code in the frontend!)

 - Just drop 0. Next version is 16.0

 Any opinions or better ideas?

 Regards,
 Kai

What is the point in 0.99? It is not like version numbers in 
semver are percentages. 0.16.x for 2.067 merge and 1.0.x for 
2.068 make most sense to me.

"Dmitri Makarov" <dmakarv gmail.com> writes:

The LDC developers should set criteria for what they consider to 
be production quality of the compiler.  Once the compiler 
satisfies the criteria the version can be advanced to 1.x. 
Anything before that is a beta version of the compiler -- be it 
0.16 or 0.256 doesn't matter.  If with the 2.068 move LDC still 
fails regression tests on OS X or Windows, although these tests 
pass on Linux, it would be premature to bump the version to 1.0, 
in my opinion.

Regards,

Dmitri


On Friday, 17 April 2015 at 05:19:05 UTC, Kai Nacke wrote:
 Hi all!

 The major D compilers are currently:

     dmd 2.067
     gdc 4.8.4
     ldc 0.15.1

 Looks like ldc is still in its early stages. Given the fact 
 that ldc is more then 10 years old (see David's presentation at 
 DConf'13) then this does not really reflect the state of ldc.

 I like to do something about the version number. Possible plans 
 I identified are:

 - The 2.067 merge gets version 0.99.0 and with the 2.068 move 
 on to 1.0.0.
   (First version with D code in the frontend!)

 - Just drop 0. Next version is 16.0

 Any opinions or better ideas?

 Regards,
 Kai

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

On 04/17/2015 01:26 PM, Dmitri Makarov via digitalmars-d-ldc wrote:
 The LDC developers should set criteria for what they consider to be
 production quality of the compiler.

LDC has been production-ready on Linux for a long time.

 Once the compiler satisfies the
 criteria the version can be advanced to 1.x. Anything before that is a
 beta version of the compiler

This is not a hard and fast rule. Some counterexamples that come to my 
mind include DOSBox, dconf and libssh. I agree, though, that pre-1 
version numbers might be perceived as less stable. And incrementing the 
major version counter quickly certainly is the fashion of the day.

 If
 with the 2.068 move LDC still fails regression tests on OS X or Windows,
 although these tests pass on Linux, it would be premature to bump the
 version to 1.0, in my opinion.

I don't think so. Windows can still remain a beta-quality platform 
target even if we choose a version number that suggests a stable release 
for Linux. After all, what about all the other platforms out there? 
FreeBSD? iOS? Haiku? Embedded targets? Case in point: Win64 isn't quite 
stable for DMD and GDC either.

  — David

Jacob Carlborg <doob me.com> writes:

On 2015-04-17 22:18, David Nadlinger via digitalmars-d-ldc wrote:

 I don't think so. Windows can still remain a beta-quality platform
 target even if we choose a version number that suggests a stable release
 for Linux. After all, what about all the other platforms out there?
 FreeBSD? iOS? Haiku? Embedded targets? Case in point: Win64 isn't quite
 stable for DMD and GDC either.

You decide which platforms are officially supported. Failing tests on 
any other platform should not block a release.

-- 
/Jacob Carlborg

"Andrea Fontana" <nospam example.com> writes:

On Friday, 17 April 2015 at 20:19:01 UTC, David Nadlinger wrote:
 LDC has been production-ready on Linux for a long time.

On Linux x86/x86-64 :)

I can't compile for arm.

"Kai Nacke" <kai redstar.de> writes:

On Tuesday, 21 April 2015 at 08:37:02 UTC, Andrea Fontana wrote:
 On Friday, 17 April 2015 at 20:19:01 UTC, David Nadlinger wrote:
 LDC has been production-ready on Linux for a long time.

 On Linux x86/x86-64 :)

 I can't compile for arm.

The missing __mulodi4 symbol? I you need to link against 
compiler-rt on arm.
Are another error?

Regards,
Kai

"Dicebot" <public dicebot.lv> writes:

On Tuesday, 21 April 2015 at 08:37:02 UTC, Andrea Fontana wrote:
 On Friday, 17 April 2015 at 20:19:01 UTC, David Nadlinger wrote:
 LDC has been production-ready on Linux for a long time.

 On Linux x86/x86-64 :)

 I can't compile for arm.

LDC should work now at least for Arch Linux   ARM (it worked last 
time I checked the packages). I had to disable intrinsics usage 
in druntime that caused missing __mulodi4 error when preparing 
the package but that was the only issue.

"bearophile" <bearophileHUGS lycos.com> writes:

Kai Nacke:

 Any opinions or better ideas?

I suggest to go to "1.0" when you feel ready.

I also suggest to drop the "2" from the ldc/ldmd name.

Bye,
bearophile

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Friday, 17 April 2015 at 05:19:05 UTC, Kai Nacke wrote:
 - The 2.067 merge gets version 0.99.0 and with the 2.068 move 
 on to 1.0.0.
   (First version with D code in the frontend!)

 - Just drop 0. Next version is 16.0

 Any opinions or better ideas?

I don't think it matters much except for in a press release. So 
better to stay humble than oversell.

I'd say stay with 0.x until DMD has settled C++ integration and 
fixated the memory model. LDC has some great options for great 
clang integration, so going 1.0 with great C++ integration would 
be a nice marketing possibility (2.x and 16.x is not as 
marketable).

Just look at all the fuzz around Go and Rust when going 1.0 (yes, 
that is the compiler, but still...)