www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP75 - Release Process

reply "David Soria Parra" <dsp experimentalworks.net> writes:
Hi,

I've been working with Martin Nowak and Andrei in the last few 
weeks to get ideas and write up a DIP on D's release process. 
With D maturing more and more I believe it is time to formalize 
the release process and do a time based release process in order 
to make release processes more predictable, easier to maintain 
and synchronize with release cycles of major distributions. 
Similar approaches have been adopted in other communities and 
worked out well. The DIP is mostly based on lessons learned from 
other communities. So please go ahead:

   http://wiki.dlang.org/DIP75

Destroy it.

  - David
Mar 06 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Nice to see more attention to this topic. On a negative side, it 
doesn't seem to be that different from what we already supposed 
to have (though it seems to imply getting rid of those annoying 
cherry-picks, if yes, that is pretty good)

In my opinion two main problems with proposed scheme are these:

1) Making solid release takes weeks from branching point. Fitting 
into strict schedule doesn't seem to be possible with current 
available resources, not without compromising regression control.

2) Separation between bug-fixes and feature additions is 
impractical in D reality. I can't remember when I had upgrade 
issues because of new features - it is almost always a legitimate 
fix that breaks the code. It is backwards compatibility that 
should define difference between major and minor versions, not 
"feature vs bugfix".

Good long-term release process should also take into account that 
GDC is naturally bound to GCC release cycle and having 
drastically different feature set introduces risk of 
fragmentation.
Mar 07 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 Mar 2015 19:05, "Dicebot via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 Nice to see more attention to this topic. On a negative side, it doesn't


seem to be that different from what we already supposed to have (though it
seems to imply getting rid of those annoying cherry-picks, if yes, that is
pretty good)

 In my opinion two main problems with proposed scheme are these:

 1) Making solid release takes weeks from branching point. Fitting into


strict schedule doesn't seem to be possible with current available
resources, not without compromising regression control.

 2) Separation between bug-fixes and feature additions is impractical in D


reality. I can't remember when I had upgrade issues because of new features
- it is almost always a legitimate fix that breaks the code. It is
backwards compatibility that should define difference between major and
minor versions, not "feature vs bugfix".

 Good long-term release process should also take into account that GDC is


naturally bound to GCC release cycle and having drastically different
feature set introduces risk of fragmentation.

Likewise, distributions that ship GDC may have longer support cycles.

One wishlist to the dlang website would be to have versioned
documentation.  For instance, pydocs let you switch between versions of a
library so you can read the documentation relevant to your installed D
compiler.
Mar 07 2015
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Mar 07, 2015 at 07:15:12PM +0000, Iain Buclaw via Digitalmars-d wrote:
[...]

 One wishlist to the dlang website would be to have versioned
 documentation.  For instance, pydocs let you switch between versions
 of a library so you can read the documentation relevant to your
 installed D compiler.


This has already been discussed, and Andrei has verbally agreed this is
a good idea. It's just a matter of somebody actually implementing it.


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are written
after the fact to describe the sorry mess that has gone on before.
Mar 07 2015
parent "tcak" <tcak gmail.com> writes:
On Saturday, 7 March 2015 at 21:33:07 UTC, H. S. Teoh wrote:

 On Sat, Mar 07, 2015 at 07:15:12PM +0000, Iain Buclaw via 
 Digitalmars-d wrote:
 [...]

 One wishlist to the dlang website would be to have versioned
 documentation.  For instance, pydocs let you switch between 
 versions
 of a library so you can read the documentation relevant to your
 installed D compiler.


 This has already been discussed, and Andrei has verbally agreed 
 this is
 a good idea. It's just a matter of somebody actually 
 implementing it.


 T


Currently, phobos documentation link is like:

http://dlang.org/phobos/std_stdio.html

Normally, IMHO, binding the version of phobos to version of D 
compiler is not a good idea though, we still could use it in the 
link as:

http://dlang.org/phobos/20661/std_stdio.html

---

Because the Phobos is being compiled based on latest compiler 
version, then bringing all documentation (Not only Phobos, but 
the language as well) under one single version number would be a 
good idea.

Too bothered to update the documentation? Just put a link and a 
message saying that, "Updating... Please refer to xxx for now".
Mar 07 2015
prev sibling next sibling parent "Israel" <tl12000 live.com> writes:
On Saturday, 7 March 2015 at 04:54:38 UTC, David Soria Parra 
wrote:

 Hi,

 I've been working with Martin Nowak and Andrei in the last few 
 weeks to get ideas and write up a DIP on D's release process. 
 With D maturing more and more I believe it is time to formalize 
 the release process and do a time based release process in 
 order to make release processes more predictable, easier to 
 maintain and synchronize with release cycles of major 
 distributions. Similar approaches have been adopted in other 
 communities and worked out well. The DIP is mostly based on 
 lessons learned from other communities. So please go ahead:

   http://wiki.dlang.org/DIP75

 Destroy it.

  - David


Would you consider adding another release process version on top 
of bugfix versions and feature versions?

I was thinking about something along the lines of "Modernization" 
versions in which old code is changed to work better, more 
efficient, etc...

out with the old and in with the new?
Mar 10 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/6/15 8:54 PM, David Soria Parra wrote:

 Hi,

 I've been working with Martin Nowak and Andrei in the last few weeks to
 get ideas and write up a DIP on D's release process. With D maturing
 more and more I believe it is time to formalize the release process and
 do a time based release process in order to make release processes more
 predictable, easier to maintain and synchronize with release cycles of
 major distributions. Similar approaches have been adopted in other
 communities and worked out well. The DIP is mostly based on lessons
 learned from other communities. So please go ahead:

    http://wiki.dlang.org/DIP75

 Destroy it.

   - David


This looks good and is simple and easy to follow enough that I am 
optimistic it can be actually observed. I do have a couple of 
notes/caveats to make:

1. A process is effective only if properly executed. I like DIP75, but a 
lot of my liking is contingent upon it being implemented in letter and 
in spirit. If there's anything in there that doesn't have on board 
Martin, David, and as many as other interested community members as 
possible, please speak up now. We need a high level of consensus to make 
this happen repeatably.

2. I'm a bit worried about the release and packaging being separated. It 
makes a lot of sense from the perspective of distributing 
responsibility, modularity, separation of concerns, simplifying 
processes, etc. It's just that if we exclude packaging from the release 
process it is just left at the discretion of less organized volunteers.

3. As I articulated in the vision document, we aim at making vibe.d an 
integral part of the D distribution. That's more than a packaging issue: 
(a) vibe.d must follow the same release process, perhaps even same 
version numbering; (b) acceptance of a release is contingent upon vibe.d 
working. I think we need to secure Sönke approval of DIP75.


Andrei
Mar 10 2015
next sibling parent "David Soria Parra" <dsp experimentalworks.net> writes:
On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu 
wrote:

 On 3/6/15 8:54 PM, David Soria Parra wrote:

 Hi,

 I've been working with Martin Nowak and Andrei in the last few 
 weeks to
 get ideas and write up a DIP on D's release process. With D 
 maturing
 more and more I believe it is time to formalize the release 
 process and
 do a time based release process in order to make release 
 processes more
 predictable, easier to maintain and synchronize with release 
 cycles of
 major distributions. Similar approaches have been adopted in 
 other
 communities and worked out well. The DIP is mostly based on 
 lessons
 learned from other communities. So please go ahead:

   http://wiki.dlang.org/DIP75

 Destroy it.

  - David


 This looks good and is simple and easy to follow enough that I 
 am optimistic it can be actually observed. I do have a couple 
 of notes/caveats to make:

 1. A process is effective only if properly executed. I like 
 DIP75, but a lot of my liking is contingent upon it being 
 implemented in letter and in spirit. If there's anything in 
 there that doesn't have on board Martin, David, and as many as 
 other interested community members as possible, please speak up 
 now. We need a high level of consensus to make this happen 
 repeatably.


Nothing to add to that, please give as much feedback as possible 
about it before we go this ptah.


 2. I'm a bit worried about the release and packaging being 
 separated. It makes a lot of sense from the perspective of 
 distributing responsibility, modularity, separation of 
 concerns, simplifying processes, etc. It's just that if we 
 exclude packaging from the release process it is just left at 
 the discretion of less organized volunteers.


This is something we can automize and if we rely on volunteers we 
want to rely them having it automized. However I am hesitating to 
add packaging to the DIP as "ideally" the release manager don't 
have to do that. In the short-term, however Martin and I will 
provide packaging and I want to see how much we can automize it. 
If you insist, however I'll add the packaging bits do the DIP.


 3. As I articulated in the vision document, we aim at making 
 vibe.d an integral part of the D distribution. That's more than 
 a packaging issue: (a) vibe.d must follow the same release 
 process, perhaps even same version numbering; (b) acceptance of 
 a release is contingent upon vibe.d working. I think we need to 
 secure Sönke approval of DIP75.


Agree. This is sensible. I hope we are making it easier for Sönke 
to sync with the DMD release which allows us to actually pull in 
up-to-date vibe for feature release.
Mar 10 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu 
wrote:

 3. As I articulated in the vision document, we aim at making 
 vibe.d an integral part of the D distribution. That's more than 
 a packaging issue: (a) vibe.d must follow the same release 
 process, perhaps even same version numbering; (b) acceptance of 
 a release is contingent upon vibe.d working. I think we need to 
 secure Sönke approval of DIP75.


Um... is this the best way to go around this?

Instead of including Vibe, we need to include Dub. Then Vibe is 
only one command away.

Vibe needs Dub anyway, doesn't it?
Mar 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 8:43 PM, Vladimir Panteleev wrote:

 On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu wrote:

 3. As I articulated in the vision document, we aim at making vibe.d an
 integral part of the D distribution. That's more than a packaging
 issue: (a) vibe.d must follow the same release process, perhaps even
 same version numbering; (b) acceptance of a release is contingent upon
 vibe.d working. I think we need to secure Sönke approval of DIP75.


 Um... is this the best way to go around this?

 Instead of including Vibe, we need to include Dub. Then Vibe is only one
 command away.

 Vibe needs Dub anyway, doesn't it?


That doesn't ensure e.g. version compatibility etc. I repeat: my vision 
is to make vibe readily available with the D distribution, just like 
druntime and phobos. Of course dub is nice to include as well but not my 
main focus here.


Andrei
Mar 10 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 March 2015 at 05:16:38 UTC, Andrei Alexandrescu 
wrote:

 That doesn't ensure e.g. version compatibility etc. I repeat: 
 my vision is to make vibe readily available with the D 
 distribution, just like druntime and phobos. Of course dub is 
 nice to include as well but not my main focus here.


It is possible to use vibe.d without dub but user experience 
would be very sub-par.
Mar 10 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 10:29 PM, Dicebot wrote:

 On Wednesday, 11 March 2015 at 05:16:38 UTC, Andrei Alexandrescu wrote:

 That doesn't ensure e.g. version compatibility etc. I repeat: my
 vision is to make vibe readily available with the D distribution, just
 like druntime and phobos. Of course dub is nice to include as well but
 not my main focus here.


 It is possible to use vibe.d without dub but user experience would be
 very sub-par.


Then I'm all for including dub as well. Let's not get lost in the 
technicalities: the point here is to provide a compelling experience out 
of the box. -- Andrei
Mar 10 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 05:16:38 UTC, Andrei Alexandrescu 
wrote:

 That doesn't ensure e.g. version compatibility etc. I repeat: 
 my vision is to make vibe readily available with the D 
 distribution, just like druntime and phobos. Of course dub is 
 nice to include as well but not my main focus here.


Andrei,

Including Dub is MUCH more important than including Vibe.

I am speaking from my limited experience, so please correct me if 
I'm wrong, but:

First, Vibe by itself will almost always not be enough. If you 
want to use Vibe, you'll also want the first-party and 
third-party add-ons to it, available on code.dlang.org. If you 
want database drivers, socket.io, protobuf, etc. etc. you will 
need to get them anyway via Dub.

Second, I don't know what's the current status of things, but two 
years ago the plan was that Vibe is too monolithic, and it needs 
to be split up into a core event system, networking / web server 
component, and HTML templating component. You can use Vibe for 
non-HTTP stuff, too.

Furthermore, Vibe is a library, with its own possibly-unstable 
API. Some projects may want to use an older version of Vibe with 
a newer version of the compiler. This is hypothetical, correct me 
if I'm wrong.

I think your vision of including Vibe with D is misguided. 
Ripping out just the core of what is now an ecosystem may even be 
a faux pas. Including Vibe without Dub is certainly a mistake, 
because inter-component versioning relies on Dub. And if you have 
Dub, Vibe and its components (including any older versions of 
such) are, like I said, a command away.
Mar 10 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:rexuctylycuzskcebotr forum.dlang.org...


 Including Dub is MUCH more important than including Vibe.

 I am speaking from my limited experience, so please correct me if I'm 
 wrong, but:


You're completely right.
Mar 10 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 March 2015 at 05:43:17 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 11 March 2015 at 05:16:38 UTC, Andrei 
 Alexandrescu wrote:

 That doesn't ensure e.g. version compatibility etc. I repeat: 
 my vision is to make vibe readily available with the D 
 distribution, just like druntime and phobos. Of course dub is 
 nice to include as well but not my main focus here.


 Andrei,

 Including Dub is MUCH more important than including Vibe.

 I am speaking from my limited experience, so please correct me 
 if I'm wrong, but:


100% true. I have actually mentioned that when plan for 2015 was 
published but it didn't catch any attention.
Mar 10 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 10:43 PM, Vladimir Panteleev wrote:

 Including Vibe without Dub is certainly a mistake, because
 inter-component versioning relies on Dub.


Fine, let's include dub too.


 And if you have Dub, Vibe and
 its components (including any older versions of such) are, like I said,
 a command away.


One command away is too much.


Andrei
Mar 10 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 06:30:52 UTC, Andrei Alexandrescu 
wrote:

 One command away is too much.


Not when the build tool will fetch dependencies as part of the 
build process anyway. A 10-second wait is not worth the 
disadvantages of moving Vibe into D.
Mar 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 11:32 PM, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 06:30:52 UTC, Andrei Alexandrescu wrote:

 One command away is too much.


 Not when the build tool will fetch dependencies as part of the build
 process anyway. A 10-second wait is not worth the disadvantages of
 moving Vibe into D.


Vladimir, please work with me on this. This is clearly subjective so 
it's really what you believe is good vs. what I believe is good. I want 
to make sure vibe releases are in sync and guaranteed to work with dmd, 
thus making for a perfectly smooth experience.

Don't forget things like the IE icon being on the desktop or not, or the 
default search engine, or the default homepage - all are big things 
although technically alternatives were always a few seconds away.

I don't have logical arguments, this could go either way. So work with 
me on this. Thanks.


Andrei
Mar 10 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 06:45:17 UTC, Andrei Alexandrescu 
wrote:

 On 3/10/15 11:32 PM, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 06:30:52 UTC, Andrei 
 Alexandrescu wrote:

 One command away is too much.


 Not when the build tool will fetch dependencies as part of the 
 build
 process anyway. A 10-second wait is not worth the 
 disadvantages of
 moving Vibe into D.


 Vladimir, please work with me on this. This is clearly 
 subjective so it's really what you believe is good vs. what I 
 believe is good. I want to make sure vibe releases are in sync 
 and guaranteed to work with dmd, thus making for a perfectly 
 smooth experience.

 Don't forget things like the IE icon being on the desktop or 
 not, or the default search engine, or the default homepage - 
 all are big things although technically alternatives were 
 always a few seconds away.

 I don't have logical arguments, this could go either way. So 
 work with me on this. Thanks.


As I have already argued, Vibe is only a piece of the puzzle.

I can only urge you to consult with someone deeply involved with 
Vibe (e.g. Sonke), as well as someone who uses Vibe and Dub 
heavily in production, before forcing a decision. It's clear that 
neither of us have enough direct experience with these projects 
to make a fully informed decision.

As you know, including IE with Windows was not something 
Microsoft got away with scot-free.
Mar 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 11:52 PM, Vladimir Panteleev wrote:

 I can only urge you to consult with someone deeply involved with Vibe
 (e.g. Sonke), as well as someone who uses Vibe and Dub heavily in
 production, before forcing a decision.


Sönke was up for it last time we communicated. This isn't forcing any 
decision as much as pushing things in order toward a greater goal. -- Andrei
Mar 10 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei Alexandrescu 
wrote:

 On 3/10/15 11:52 PM, Vladimir Panteleev wrote:

 I can only urge you to consult with someone deeply involved 
 with Vibe
 (e.g. Sonke), as well as someone who uses Vibe and Dub heavily 
 in
 production, before forcing a decision.


 Sönke was up for it last time we communicated. This isn't 
 forcing any decision as much as pushing things in order toward 
 a greater goal. -- Andrei


If we want Vibe.d to keep in sync with D, isn't the easiest way 
to do that making it part of the standard library as etc.vibe.* 
or something?
Mar 11 2015
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 March 2015 at 07:01:02 UTC, Meta wrote:

 On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei 
 Alexandrescu wrote:

 On 3/10/15 11:52 PM, Vladimir Panteleev wrote:

 I can only urge you to consult with someone deeply involved 
 with Vibe
 (e.g. Sonke), as well as someone who uses Vibe and Dub 
 heavily in
 production, before forcing a decision.


 Sönke was up for it last time we communicated. This isn't 
 forcing any decision as much as pushing things in order toward 
 a greater goal. -- Andrei


 If we want Vibe.d to keep in sync with D, isn't the easiest way 
 to do that making it part of the standard library as etc.vibe.* 
 or something?


Simply adding it to auto-tester would achieve the same goal 
without introducing awkward library paths.
Mar 11 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-03-11 07:56, Andrei Alexandrescu wrote:


 Sönke was up for it last time we communicated. This isn't forcing any
 decision as much as pushing things in order toward a greater goal. --
 Andrei


I agree with Dicebot and Vladimir that including vibe.d without Dub 
might cause more harm than doing good. But I don't see why we can't 
include both.

-- 
/Jacob Carlborg
Mar 11 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei Alexandrescu 
wrote:

 On 3/10/15 11:52 PM, Vladimir Panteleev wrote:

 I can only urge you to consult with someone deeply involved 
 with Vibe
 (e.g. Sonke), as well as someone who uses Vibe and Dub heavily 
 in
 production, before forcing a decision.


 Sönke was up for it last time we communicated.


Question, was he merely OK with it or did he agree that this is 
genuinely a good idea?
Mar 11 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 1:10 AM, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei Alexandrescu wrote:

 On 3/10/15 11:52 PM, Vladimir Panteleev wrote:

 I can only urge you to consult with someone deeply involved with Vibe
 (e.g. Sonke), as well as someone who uses Vibe and Dub heavily in
 production, before forcing a decision.


 Sönke was up for it last time we communicated.


 Question, was he merely OK with it or did he agree that this is
 genuinely a good idea?


The latter, but I'll let him spek for himself. -- Andrei
Mar 11 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-11 07:45, Andrei Alexandrescu wrote:


 Vladimir, please work with me on this. This is clearly subjective so
 it's really what you believe is good vs. what I believe is good. I want
 to make sure vibe releases are in sync and guaranteed to work with dmd,
 thus making for a perfectly smooth experience.

 Don't forget things like the IE icon being on the desktop or not, or the
 default search engine, or the default homepage - all are big things
 although technically alternatives were always a few seconds away.

 I don't have logical arguments, this could go either way. So work with
 me on this. Thanks.


How about including both Dub and vibe.d? I mean that one would _not_ 
need to run Dub to get vibe.d, but Dub would be available for other 
libraries.

-- 
/Jacob Carlborg
Mar 11 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 12:17 AM, Jacob Carlborg wrote:

 How about including both Dub and vibe.d?


That sounds good. -- Andrei
Mar 11 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 06:45:17 UTC, Andrei Alexandrescu 
wrote:

 I want to make sure vibe releases are in sync and guaranteed to 
 work with dmd, thus making for a perfectly smooth experience.


How will bundling Vibe with D achieve that goal?

What will ACTUALLY change by bundling Vibe with D?

What happens if a regression occurs in Vibe just before a D 
release? Do we block the release for the sake of Vibe? What if 
there's no one around to fix it? We have enough problems with 
blocking bugs in Dub/Vibe-related components in the dlang.org 
repo already.

What happens if we discover a regression in Vibe after a D 
release? Do we make a point release just for the sake of Vibe?

What if Vibe needs to iterate faster than DMD's release cycle?

My question about Vibe API versioning still stands, what if 
people want to use an older Vibe with a newer DMD?

Precedent shows that Vibe and related components simply do not 
have a bus factor high enough to not be a liability if included 
with D.

I am trying to work with you here. We just have different values 
on what is actually important, or there is something more to this 
plan that I don't see, something more than just including Vibe in 
dmd.zip.

We do not have a strong precedent for this. The closest thing we 
have are things like Dustmite, which are so specialized that they 
don't matter in this case, and Visual D, which I'm not really 
sure greatly benefited from the exposure - we've covered one IDE 
among many, and despite moving the project under 
github.com/D-P-L, Rainer remains the sole maintainer. And you 
know the story with DDox.

What is indubitably, actually, very important, and something I'm 
surprised you haven't pushed for since long ago, is making it 
EASY to get more things. Dub absolutely must be a part of D, and 
not today but one or more years ago. There is now a rift in this 
community, between people who use code.dlang.org and its 
packages, and those who do not. This is not close to the 
Tango/Phobos split, but we cannot afford anything like this again.

Coming from a language with a package manager, and then trying to 
build a project with a dozen dependencies by manually cloning the 
repositories and making sure they are the correct version, is 
madness. A package manager encourages people to build many small 
reusable components, because the overhead of managing each 
component becomes very small, and this is something we really 
want.

 From this perspective, Vibe itself is not that special. It is one 
big piece of the puzzle, but its value is greatly diminished in 
isolation.

You don't need to bring in Vibe in D itself, you need to bring in 
the entire ecosystem.
Mar 11 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 12:19 AM, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 06:45:17 UTC, Andrei Alexandrescu wrote:

 I want to make sure vibe releases are in sync and guaranteed to work
 with dmd, thus making for a perfectly smooth experience.


 How will bundling Vibe with D achieve that goal?

 What will ACTUALLY change by bundling Vibe with D?


Many people know of D but not of vibe.


 What happens if a regression occurs in Vibe just before a D release? Do
 we block the release for the sake of Vibe?


Yes.


 What if there's no one around
 to fix it? We have enough problems with blocking bugs in
 Dub/Vibe-related components in the dlang.org repo already.


We need to rally support around it.


 What happens if we discover a regression in Vibe after a D release? Do
 we make a point release just for the sake of Vibe?


Yes.


 What if Vibe needs to iterate faster than DMD's release cycle?


A bundle deal is what it is.


 My question about Vibe API versioning still stands, what if people want
 to use an older Vibe with a newer DMD?


They can in the same way they can use an older Phobos. It's up to them 
to make it work.


 Precedent shows that Vibe and related components simply do not have a
 bus factor high enough to not be a liability if included with D.


There is one way to increase the bus factor. Making vibe more visible is 
better for vibe folks and of course for users.


 I am trying to work with you here.


It doesn't seem so to me. You find easy weaknesses in my vision and pump 
on them instead of working on making it stronger. That's the easy "but 
that business won't work, and here are the reasons why" approach. The 
harder part is finding ways to make it work by overcoming its weaknesses.


 We just have different values on what
 is actually important, or there is something more to this plan that I
 don't see, something more than just including Vibe in dmd.zip.

 We do not have a strong precedent for this.


If we continue to do what we've been doing, we'll progress at the rate 
we've been progressing. That's not enough.


 The closest thing we have
 are things like Dustmite, which are so specialized that they don't
 matter in this case, and Visual D, which I'm not really sure greatly
 benefited from the exposure - we've covered one IDE among many, and
 despite moving the project under github.com/D-P-L, Rainer remains the
 sole maintainer. And you know the story with DDox.


Yah, that's a bummer. Yet neither of these is as comprehensive as vibe.


 What is indubitably, actually, very important, and something I'm
 surprised you haven't pushed for since long ago, is making it EASY to
 get more things. Dub absolutely must be a part of D, and not today but
 one or more years ago. There is now a rift in this community, between
 people who use code.dlang.org and its packages, and those who do not.
 This is not close to the Tango/Phobos split, but we cannot afford
 anything like this again.


Agreed. Dub should be in.


 Coming from a language with a package manager, and then trying to build
 a project with a dozen dependencies by manually cloning the repositories
 and making sure they are the correct version, is madness. A package
 manager encourages people to build many small reusable components,
 because the overhead of managing each component becomes very small, and
 this is something we really want.

  From this perspective, Vibe itself is not that special. It is one big
 piece of the puzzle, but its value is greatly diminished in isolation.

 You don't need to bring in Vibe in D itself, you need to bring in the
 entire ecosystem.


We must make vibe part of D.


Andrei
Mar 11 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu 
wrote:

 On 3/11/15 12:19 AM, Vladimir Panteleev wrote:

 What will ACTUALLY change by bundling Vibe with D?


 Many people know of D but not of vibe.


Precedent shows that this does not work. Including Dustmite with 
D did not solve the issue that you have to know about Dustmite 
before you can even think about using it.

If you want to increase Vibe's visibility, adding a few links to 
dlang.org will serve this goal much better.


 What happens if a regression occurs in Vibe just before a D 
 release? Do
 we block the release for the sake of Vibe?


 Yes.


Are you really OK with this? Is everyone OK with this?

Everyone who does not use Vibe almost certainly is not going to 
be OK with this.


 What if there's no one around
 to fix it? We have enough problems with blocking bugs in
 Dub/Vibe-related components in the dlang.org repo already.


 We need to rally support around it.


Precedent shows that this does not work. Regressions have stayed 
unfixed up to and past prior D releases.


 My question about Vibe API versioning still stands, what if 
 people want
 to use an older Vibe with a newer DMD?


 They can in the same way they can use an older Phobos. It's up 
 to them to make it work.


Is everyone OK with this? I don't have enough experience with 
Vibe to know how important this is.


 Precedent shows that Vibe and related components simply do not 
 have a
 bus factor high enough to not be a liability if included with 
 D.


 There is one way to increase the bus factor. Making vibe more 
 visible is better for vibe folks and of course for users.


Precedent shows that this does not work. Neither Dustmite nor 
Visual D magically got an increase in developers.


 I am trying to work with you here.


 It doesn't seem so to me. You find easy weaknesses in my vision 
 and pump on them instead of working on making it stronger. 
 That's the easy "but that business won't work, and here are the 
 reasons why" approach. The harder part is finding ways to make 
 it work by overcoming its weaknesses.


No, you're saying that just because I don't agree with your 
immediate goal, then I'm not working with you. I indeed do not 
agree with your immediate goal, but I do agree with the long-term 
goal.


 We do not have a strong precedent for this.


 If we continue to do what we've been doing, we'll progress at 
 the rate we've been progressing. That's not enough.


This is wishful thinking. Precedent shows that this does not 
work. Working force is not going to materialize from thin air 
just because you attract more attention to it.


 The closest thing we have
 are things like Dustmite, which are so specialized that they 
 don't
 matter in this case, and Visual D, which I'm not really sure 
 greatly
 benefited from the exposure - we've covered one IDE among 
 many, and
 despite moving the project under github.com/D-P-L, Rainer 
 remains the
 sole maintainer. And you know the story with DDox.


 Yah, that's a bummer. Yet neither of these is as comprehensive 
 as vibe.


This just means that the problem will be stronger with Vibe. Vibe 
is more complicated, and there will be fewer people familiar with 
all parts of it. Will there be enough to keep it running in pace 
with D?
Mar 11 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-03-11 08:47, Vladimir Panteleev wrote:


 If you want to increase Vibe's visibility, adding a few links to
 dlang.org will serve this goal much better.


I agree. Bundle Dub and make vibe.d clearly visible on dlang.org.

-- 
/Jacob Carlborg
Mar 11 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-03-11 08:47, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:

 On 3/11/15 12:19 AM, Vladimir Panteleev wrote:





 What happens if a regression occurs in Vibe just before a D release? Do
 we block the release for the sake of Vibe?


 Yes.


 Are you really OK with this? Is everyone OK with this?

 Everyone who does not use Vibe almost certainly is not going to be OK
 with this.


I like the semantic version scheme that Dub uses (including vibe.d). I 
have never liked the way D is released. Both big new features and small 
bug fixes in the same release.

-- 
/Jacob Carlborg
Mar 11 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu 
wrote:

 It doesn't seem so to me. You find easy weaknesses in my vision 
 and pump on them instead of working on making it stronger. 
 That's the easy "but that business won't work, and here are the 
 reasons why" approach. The harder part is finding ways to make 
 it work by overcoming its weaknesses.


Here is a counter-proposal:

1. Add Dub to D.

2. Add a "web development" link in the sidebar, which simply 
links to vibed.org.

3. Add an example on the front page on how to create a simple web 
server. It needs to list only main.d and package.json, and the 
dub command line to build it. A package.json will be needed for 
non-trivial things anyway, so might as well get that out of the 
way anyway.

4. Unite the Vibe.d forum with forum.dlang.org. I should be able 
to do this by making forum.dlang.org connect to it via NNTP.

I think this will achieve much of your goal without the drawbacks.
Mar 11 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my vision and
 pump on them instead of working on making it stronger. That's the easy
 "but that business won't work, and here are the reasons why" approach.
 The harder part is finding ways to make it work by overcoming its
 weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply links to
 vibed.org.

 3. Add an example on the front page on how to create a simple web
 server. It needs to list only main.d and package.json, and the dub
 command line to build it. A package.json will be needed for non-trivial
 things anyway, so might as well get that out of the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do
 this by making forum.dlang.org connect to it via NNTP.

 I think this will achieve much of your goal without the drawbacks.


I would like to add putting focus on getting libasync[0] phobos ready 
instead of the vibe.d direction.

It might be a lot younger, but it is also have a lot smaller scope.

Perhaps even a rewrite of std.socket to use it?

It is a lot of work, but its probably a more manageable unit of work in 
the short term.

[0] https://github.com/etcimon/libasync
Mar 11 2015
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole 
wrote:

 On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei 
 Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my 
 vision and
 pump on them instead of working on making it stronger. That's 
 the easy
 "but that business won't work, and here are the reasons why" 
 approach.
 The harder part is finding ways to make it work by overcoming 
 its
 weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply 
 links to
 vibed.org.

 3. Add an example on the front page on how to create a simple 
 web
 server. It needs to list only main.d and package.json, and the 
 dub
 command line to build it. A package.json will be needed for 
 non-trivial
 things anyway, so might as well get that out of the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be 
 able to do
 this by making forum.dlang.org connect to it via NNTP.

 I think this will achieve much of your goal without the 
 drawbacks.


 I would like to add putting focus on getting libasync[0] phobos 
 ready instead of the vibe.d direction.

 It might be a lot younger, but it is also have a lot smaller 
 scope.

 Perhaps even a rewrite of std.socket to use it?

 It is a lot of work, but its probably a more manageable unit of 
 work in the short term.

 [0] https://github.com/etcimon/libasync



+100000!!!

and yes, we are using vibe.d in production, but libasync also.
---
Paolo
Mar 11 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 11/03/2015 11:04 p.m., Paolo Invernizzi wrote:

 On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole wrote:

 On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my vision and
 pump on them instead of working on making it stronger. That's the easy
 "but that business won't work, and here are the reasons why" approach.
 The harder part is finding ways to make it work by overcoming its
 weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply links to
 vibed.org.

 3. Add an example on the front page on how to create a simple web
 server. It needs to list only main.d and package.json, and the dub
 command line to build it. A package.json will be needed for non-trivial
 things anyway, so might as well get that out of the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do
 this by making forum.dlang.org connect to it via NNTP.

 I think this will achieve much of your goal without the drawbacks.


 I would like to add putting focus on getting libasync[0] phobos ready
 instead of the vibe.d direction.

 It might be a lot younger, but it is also have a lot smaller scope.

 Perhaps even a rewrite of std.socket to use it?

 It is a lot of work, but its probably a more manageable unit of work
 in the short term.

 [0] https://github.com/etcimon/libasync



 +100000!!!

 and yes, we are using vibe.d in production, but libasync also.
 ---
 Paolo


IMO it makes more sense then vibe.d itself does. Yes vibe.d is what end 
developers will use. But libasync is doing a lot of the lower level work 
needed to make vibe.d useful.

If we can get the low level parts decent, vibe.d will benefit greatly 
from it.
Mar 11 2015
prev sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole 
wrote:

 On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei 
 Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my 
 vision and
 pump on them instead of working on making it stronger. That's 
 the easy
 "but that business won't work, and here are the reasons why" 
 approach.
 The harder part is finding ways to make it work by overcoming 
 its
 weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply 
 links to
 vibed.org.

 3. Add an example on the front page on how to create a simple 
 web
 server. It needs to list only main.d and package.json, and the 
 dub
 command line to build it. A package.json will be needed for 
 non-trivial
 things anyway, so might as well get that out of the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be 
 able to do
 this by making forum.dlang.org connect to it via NNTP.

 I think this will achieve much of your goal without the 
 drawbacks.


 I would like to add putting focus on getting libasync[0] phobos 
 ready instead of the vibe.d direction.

 It might be a lot younger, but it is also have a lot smaller 
 scope.

 Perhaps even a rewrite of std.socket to use it?

 It is a lot of work, but its probably a more manageable unit of 
 work in the short term.

 [0] https://github.com/etcimon/libasync


+1
While vibe.d might be too big(?) for phobos, async sockets and 
file I/O would be awesome.
Mar 11 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 1:00 AM, Vladimir Panteleev wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my vision and
 pump on them instead of working on making it stronger. That's the easy
 "but that business won't work, and here are the reasons why" approach.
 The harder part is finding ways to make it work by overcoming its
 weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply links to
 vibed.org.

 3. Add an example on the front page on how to create a simple web
 server. It needs to list only main.d and package.json, and the dub
 command line to build it. A package.json will be needed for non-trivial
 things anyway, so might as well get that out of the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do
 this by making forum.dlang.org connect to it via NNTP.

 I think this will achieve much of your goal without the drawbacks.


These are good steps to take. If after taking them we're in a good 
place, we can stop there. -- Andrei
Mar 11 2015
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 11 March 2015 at 08:00:22 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei 
 Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my 
 vision and pump on them instead of working on making it 
 stronger. That's the easy "but that business won't work, and 
 here are the reasons why" approach. The harder part is finding 
 ways to make it work by overcoming its weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply 
 links to vibed.org.

 3. Add an example on the front page on how to create a simple 
 web server. It needs to list only main.d and package.json, and 
 the dub command line to build it. A package.json will be needed 
 for non-trivial things anyway, so might as well get that out of 
 the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be 
 able to do this by making forum.dlang.org connect to it via 
 NNTP.

 I think this will achieve much of your goal without the 
 drawbacks.


Excellent points and thank you so much for defending DUB and the 
ecosystem :)
Mar 11 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 11 March 2015 at 08:00:22 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei 
 Alexandrescu wrote:

 It doesn't seem so to me. You find easy weaknesses in my 
 vision and pump on them instead of working on making it 
 stronger. That's the easy "but that business won't work, and 
 here are the reasons why" approach. The harder part is finding 
 ways to make it work by overcoming its weaknesses.


 Here is a counter-proposal:

 1. Add Dub to D.

 2. Add a "web development" link in the sidebar, which simply 
 links to vibed.org.

 3. Add an example on the front page on how to create a simple 
 web server. It needs to list only main.d and package.json, and 
 the dub command line to build it. A package.json will be needed 
 for non-trivial things anyway, so might as well get that out of 
 the way anyway.

 4. Unite the Vibe.d forum with forum.dlang.org. I should be 
 able to do this by making forum.dlang.org connect to it via 
 NNTP.

 I think this will achieve much of your goal without the 
 drawbacks.


Thanks Vladimir, this is really how we should approach things IMO.
Mar 13 2015
prev sibling parent reply "Anon" <cant stand.dub> writes:
On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev 
wrote:

 What is indubitably, actually, very important, and something 
 I'm surprised you haven't pushed for since long ago, is making 
 it EASY to get more things. Dub absolutely must be a part of D, 
 and not today but one or more years ago. There is now a rift in 
 this community, between people who use code.dlang.org and its 
 packages, and those who do not.


And those of us who don't use dub are *not* going to magically
start using dub just because it is bundled with dmd. I don't use
dub because it doesn't benefit me in any way, and really only
gets in my way.


 Coming from a language with a package manager, and then trying 
 to build a project with a dozen dependencies by manually 
 cloning the repositories and making sure they are the correct 
 version, is madness. A package manager encourages people to 
 build many small reusable components, because the overhead of 
 managing each component becomes very small, and this is 
 something we really want.


And any package manager that only operates in source, demands
a central repository (that effectively just redirects to the
actual Git repos), and only works for one language is utterly
worthless for real world projects.

Not to mention, putting extra tools like dustmite and dub in dmd
will only ever benefit dmd users, not those of us who use ldc or
gdc.

Ignoring that for a moment, where does it stop? Do we include an
editor? [sarcasm] Why not? Every D developer needs to edit their
code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
and bundle that with dmd. [/sarcasm]
Mar 11 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 9:27 AM, Anon wrote:

 On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev wrote:

 What is indubitably, actually, very important, and something I'm
 surprised you haven't pushed for since long ago, is making it EASY to
 get more things. Dub absolutely must be a part of D, and not today but
 one or more years ago. There is now a rift in this community, between
 people who use code.dlang.org and its packages, and those who do not.


 And those of us who don't use dub are *not* going to magically
 start using dub just because it is bundled with dmd. I don't use
 dub because it doesn't benefit me in any way, and really only
 gets in my way.


That's fine. The thing about tooling is it can be ignored if found 
unnecessary. The trick is providing tooling that works well for a 
majority of users and that the other tools may assume they exist.


 Coming from a language with a package manager, and then trying to
 build a project with a dozen dependencies by manually cloning the
 repositories and making sure they are the correct version, is madness.
 A package manager encourages people to build many small reusable
 components, because the overhead of managing each component becomes
 very small, and this is something we really want.


 And any package manager that only operates in source, demands
 a central repository (that effectively just redirects to the
 actual Git repos), and only works for one language is utterly
 worthless for real world projects.

 Not to mention, putting extra tools like dustmite and dub in dmd
 will only ever benefit dmd users, not those of us who use ldc or
 gdc.


That's entirely reasonable. Each distribution has the freedom to bundle 
whichever tools it finds fit.

I would agree it would be bad if dustmite and dub were locked-in to only 
work with dmd. Is that the case?


 Ignoring that for a moment, where does it stop? Do we include an
 editor? [sarcasm] Why not? Every D developer needs to edit their
 code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
 and bundle that with dmd. [/sarcasm]


Probably "where does it stop" is a good question to ask later.


Andrei
Mar 11 2015
next sibling parent "Anon" <cant stand.dub> writes:
On Wednesday, 11 March 2015 at 16:35:22 UTC, Andrei Alexandrescu 
wrote:

 On 3/11/15 9:27 AM, Anon wrote:

 Not to mention, putting extra tools like dustmite and dub in 
 dmd
 will only ever benefit dmd users, not those of us who use ldc 
 or
 gdc.


 That's entirely reasonable. Each distribution has the freedom 
 to bundle whichever tools it finds fit.


My point with that (that I forgot to actually type) was that I
feel there would be better mileage if D tools were packaged up
and provided apart from the compiler. Then the same tools set
can be used regardless of compiler choice, and (perhaps more
importantly) update independently of DFE updates. Some tools
are dependent on the compiler being used, and wouldn't work for
independent distribution, but for the others, it makes more
sense (to me anyway) to make that a separate download.
Of course, installers could be set up to also download that
zip if desired.

By way of example, I'd expect clang-format to be bundled with
clang, but I wouldn't expect (or want) valgrind to be bundled
with clang or gcc. I could however, see the value of a single
download that included valgrind and astyle.


 I would agree it would be bad if dustmite and dub were 
 locked-in to only work with dmd. Is that the case?


Not to my knowledge, but binary releases for most dmd tools are
only available with dmd, which is not ideal. It also creates
a potential ambiguity, since dmd is not redistributable
without explicit permission from Walter, but most of the tools
included with dmd are. Separating the tools from the compiler
allows a very easy line to be drawn between what is and might
not be redistributable.
Mar 11 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 11 March 2015 at 16:35:22 UTC, Andrei Alexandrescu 
wrote:

 I would agree it would be bad if dustmite and dub were 
 locked-in to only work with dmd. Is that the case?


No, both support all three D compilers.
Mar 13 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-11 17:27, Anon wrote:


 Ignoring that for a moment, where does it stop? Do we include an
 editor? [sarcasm] Why not? Every D developer needs to edit their
 code! Let's go ahead and call Eclipse+DDT the "standard" D editor,
 and bundle that with dmd. [/sarcasm]


I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's.

-- 
/Jacob Carlborg
Mar 12 2015
next sibling parent "Anon" <cant stand.dub> writes:
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote:

 On 2015-03-11 17:27, Anon wrote:


 Ignoring that for a moment, where does it stop? Do we include 
 an
 editor? [sarcasm] Why not? Every D developer needs to edit 
 their
 code! Let's go ahead and call Eclipse+DDT the "standard" D 
 editor,
 and bundle that with dmd. [/sarcasm]


 I don't see why not. Both Microsoft and Apple ship an IDE with 
 their SDK's.


That's an IDE that includes a compiler, not a compiler that 
includes an IDE. You aren't downloading cl, you're downloading 
VisualStudio. That you also get cl is an implementation detail. 
If Bruno wanted to release a build of Eclipse+DDT that came with 
a compiler, I'd have no problem with that.
Mar 12 2015
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote:

 On 2015-03-11 17:27, Anon wrote:


 Ignoring that for a moment, where does it stop? Do we include 
 an
 editor? [sarcasm] Why not? Every D developer needs to edit 
 their
 code! Let's go ahead and call Eclipse+DDT the "standard" D 
 editor,
 and bundle that with dmd. [/sarcasm]


 I don't see why not. Both Microsoft and Apple ship an IDE with 
 their SDK's.


The SDKs ship with Visual Studio, not the other way around. Both 
the Windows SDK and .NET Framework/SDK are separate products. The 
.NET Framework itself includes the .NET compiler, which Visual 
Studio uses, and the Windows SDK includes cl.exe which is the 
C/C++ compiler. Neither require Visual Studio.

It's good to have a single installer that includes everything you 
need to get started (dmd, dub, IDE / IDE plugin) like Visual 
Studio is (cl/csc, Nuget, VS), but the compiler itself should 
definitely not ship with an IDE.
Mar 12 2015
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 March 2015 at 06:30:52 UTC, Andrei Alexandrescu 
wrote:

 On 3/10/15 10:43 PM, Vladimir Panteleev wrote:

 Including Vibe without Dub is certainly a mistake, because
 inter-component versioning relies on Dub.


 Fine, let's include dub too.


There is 1.0.0 milestone in dub GitHub repo : 
https://github.com/D-Programming-Language/dub/milestones/1.0.0

It includes bunch of issues created ~year ago when we first 
started to consider what it would take to make a somewhat stable 
dub release (distributing with compiler puts more pressure on 
stability). Sadly, no one has really worked on those which is why 
further dub integration has stalled. Some sort of call for arms 
may help.
Mar 11 2015
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 11 March 2015 at 05:43:17 UTC, Vladimir Panteleev 
wrote:

 Furthermore, Vibe is a library, with its own possibly-unstable 
 API. Some projects may want to use an older version of Vibe 
 with a newer version of the compiler. This is hypothetical, 
 correct me if I'm wrong.

 I think your vision of including Vibe with D is misguided. 
 Ripping out just the core of what is now an ecosystem may even 
 be a faux pas. Including Vibe without Dub is certainly a 
 mistake, because inter-component versioning relies on Dub. And 
 if you have Dub, Vibe and its components (including any older 
 versions of such) are, like I said, a command away.


Couldn't agree more.
Mar 11 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu 
wrote:

 3. As I articulated in the vision document, we aim at making 
 vibe.d an integral part of the D distribution. That's more than 
 a packaging issue: (a) vibe.d must follow the same release 
 process, perhaps even same version numbering; (b) acceptance of 
 a release is contingent upon vibe.d working. I think we need to 
 secure Sönke approval of DIP75.


 Andrei


Don't special-case vibe.d. Dub is the key to the ecosystem. Once 
you have dub, vibe.d comes for free, even if you don't want to 
use dub for your project.

Guarantees of operation with particular compiler versions is 
something for vibe.d versioning, which in turn is the job of dub 
to manage.

Not breaking vibe.d with dmd/phobos regressions needs the 
auto-tester, not release bundling.
Mar 11 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/15 3:53 AM, John Colvin wrote:

 On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu wrote:

 3. As I articulated in the vision document, we aim at making vibe.d an
 integral part of the D distribution. That's more than a packaging
 issue: (a) vibe.d must follow the same release process, perhaps even
 same version numbering; (b) acceptance of a release is contingent upon
 vibe.d working. I think we need to secure Sönke approval of DIP75.


 Andrei


 Don't special-case vibe.d. Dub is the key to the ecosystem.


Dub is great. Vibe is great. We need to include both. -- Andrei
Mar 11 2015