DIP75 - Release Process

[Andrei Alexandrescu via Digitalmars-d]

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