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

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.

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.

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.

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".

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?

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

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.

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?

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