On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
> I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen.
>
> We have to do better than this.
>
> Atila

I don't think this is unusual even outside of D.
At least Microsoft seems to be willing to break your build if it moves things forward. For example, there are projects that worked fine on MSVC 15.4 (VS2017), but broke if you installed the update to 15.5 (or auto-updated in Visual Studio).
You can't test everything.

A lot of the "regular" companies, that desire high stability, typically use very old compilers and just workaround the bugs they know.
For a D example, I think Sociomantic was using D1 for a long time just because it was stable for them.

And if you need stability, why would you update the compiler without local testing and reserving time to fix any issues?

On Tue, Mar 06, 2018 at 08:50:37PM +0000, Jack Stouffer via Digitalmars-d-announce wrote: [...]
> Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?

Please don't. I dread the day my daily dmd toolchain update script will have to depend on dub just to be able to build a working compiler.

But personal preferences aside, one blocker to this is that dmd and phobos (as well as druntime) development often go in lockstep, and sometimes breaking transitions must be coordinated between them so that git master is always buildable.  If dmd and phobos were separate repos, it would make this coordination much, much, more difficult.

(Though, on second thoughts, that's not necessarily a bad thing, as it will force us to actually face these issues and make Phobos buildable with multiple compiler versions, which currently is not well supported, if it works at all, because of said interdependence. This would also force us to dogfood our release / deprecation processeses, which will allow us to notice problems early and to experience what end users would experience when transitioning between compiler versions. It *will* add more workload to an already thin Phobos dev team, though. So there's that.)


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
>
> Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?

That's the day I stop using D.

I do not, and will not, use dub. Full stop.

Same goes for Rust ;-)

On 07/03/2018 2:54 PM, psychoticRabbit wrote:
> On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
>>
>> Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?
> 
> That's the day I stop using D.
> 
> I do not, and will not, use dub. Full stop.
> 
> Same goes for Rust ;-)

Under such arrangement nobody is forcing you to use dub.
We wouldn't break distribution or usage of dmd just because of changing a make file to dub. That's just silly.

On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
> On 3/6/18 2:30 PM, Martin Nowak wrote:
>> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>
>>> But if needed, you could have your dub package depend on a prior version.
>> 
>> http://code.dlang.org/packages/stdx-allocator ;)
>> 
>
> This is the answer, vibe.d should depend on stdx-allocator.
>
> -Steve

Vibe.d (and a lot of other projects) do depend on this package, see e.g.

https://github.com/vibe-d/vibe.d/pull/1983

Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.

On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
> On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
>> On 3/6/18 2:30 PM, Martin Nowak wrote:
>>> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>>
>>>> But if needed, you could have your dub package depend on a prior version.
>>> 
>>> http://code.dlang.org/packages/stdx-allocator ;)
>>> 
>>
>> This is the answer, vibe.d should depend on stdx-allocator.
>>
>> -Steve
>
> Vibe.d (and a lot of other projects) do depend on this package, see e.g.
>
> https://github.com/vibe-d/vibe.d/pull/1983
>
> Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.

The point is just to persuade Sonke to do his development in the minor version and increase it during every vibe-d release, and keep the patch version for fast fixes of the latest released vibe-d when a new version of the compiler is being released.

The actual policy is just an ask for problems...

It's not a big deal to fix the breakage on the latest released vibe-d code, it's a fast process. But it's a problem in just coordinating the next release of vibe-d with the release of the compiler, if you need to do this, like in this case.

/Paolo

Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:
> On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
>> On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
>>> On 3/6/18 2:30 PM, Martin Nowak wrote:
>>>> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>>>
>>>>> But if needed, you could have your dub package depend on a prior version.
>>>>
>>>> http://code.dlang.org/packages/stdx-allocator ;)
>>>>
>>>
>>> This is the answer, vibe.d should depend on stdx-allocator.
>>>
>>> -Steve
>>
>> Vibe.d (and a lot of other projects) do depend on this package, see e.g.
>>
>> https://github.com/vibe-d/vibe.d/pull/1983
>>
>> Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
> 
> The point is just to persuade Sonke to do his development in the minor version and increase it during every vibe-d release, and keep the patch version for fast fixes of the latest released vibe-d when a new version of the compiler is being released.
> 
> The actual policy is just an ask for problems...
> 
> It's not a big deal to fix the breakage on the latest released vibe-d code, it's a fast process. But it's a problem in just coordinating the next release of vibe-d with the release of the compiler, if you need to do this, like in this case.
> 
> /Paolo
> 

Well, for all of the recent releases we made sure that there was no breakage for new compiler versions. This release was an exception, because I didn't manage to put out the fixed release in time. The plan is to have all future releases go back to the normal mode where the new compiler version always works.

Since std.experimental isn't involved from now on, it shouldn't even be necessary anymore to put out new vibe.d releases for new DMD versions, because DMD/Phobos already checks for regressions against vibe.d and all breaking changes should simply result in a deprecation warning.

As for the versioning scheme, currently almost all new releases have some small breaking change or deprecation. If I'd use the "minor" version for that, then there would be no way to signal that a release makes broad and more disruptive changes, such as the 0.8.0 release. But all of this will change, as the remaining parts get pushed to separate repositories one-by-one, with their own version starting at 1.0.0.

On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:

> Well, for all of the recent releases we made sure that there was no breakage for new compiler versions. This release was an exception, because I didn't manage to put out the fixed release in time. The plan is to have all future releases go back to the normal mode where the new compiler version always works.
>
> Since std.experimental isn't involved from now on, it shouldn't even be necessary anymore to put out new vibe.d releases for new DMD versions, because DMD/Phobos already checks for regressions against vibe.d and all breaking changes should simply result in a deprecation warning.

That's fine, thanks.

> As for the versioning scheme, currently almost all new releases have some small breaking change or deprecation. If I'd use the "minor" version for that, then there would be no way to signal that a release makes broad and more disruptive changes, such as the 0.8.0 release. But all of this will change, as the remaining parts get pushed to separate repositories one-by-one, with their own version starting at 1.0.0.

I understand your reasoning, but there's value in being able to just rapidly fix something with a new release, or just port some master bug-fixes into a released version branch.

DMD is experiencing a very enjoyable release process of patch versions, thanks to Martin and the team.

It your concern is only related to the best way to inform the users about a broad and disruptive change in vibe-d, I suggest to simply use the usual channels for that, change logs and announce forum.

My impression is that there's a lot of value in using patch for patch, instead of using patch for development, also in a zero major, so I maybe you should consider that change, or at least, investigate a little about that opportunity.

/Paolo

On 3/6/18 11:02 PM, Seb wrote:
> On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
>> On 3/6/18 2:30 PM, Martin Nowak wrote:
>>> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>>
>>>> But if needed, you could have your dub package depend on a prior version.
>>>
>>> http://code.dlang.org/packages/stdx-allocator ;)
>>>
>>
>> This is the answer, vibe.d should depend on stdx-allocator.
>>
>> -Steve
> 
> Vibe.d (and a lot of other projects) do depend on this package, see e.g.
> 
> https://github.com/vibe-d/vibe.d/pull/1983
> 
> Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.

Hm... so basically this was fixed back in December, but just hadn't been released? I think then this seems like an unfortunate, but temporary problem that should be OK for the future.

In any case, I think this shows we need to move our proving grounds to an external package. Much better to do it that way than to couple breaking changes on an experimental package with dmd/phobos fixes.

-Steve

On 3/6/18 3:50 PM, Jack Stouffer wrote:
> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>> That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version.
> 
> The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules.

Promotion of modules is a different discussion. I think std.experimental is fine as a project, but just needs to be decoupled with needed compiler and stable library fixes.

To put it in terms of Atila's reference, it's like we coupled the breaking changes of boost-experimental with critical clang fixes.

> Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?

No. Phobos has a reasonably stable API, and we need to keep it that way. There are too many coupled changes with Phobos and DMD that I think we would be asking for a mountain of "Why is this version of Phobos not compatible with this version of DMD?" bugs.

-Steve