DIP75 - Release Process
David Soria Parra via Digitalmars-d
digitalmars-d at puremagic.com
Tue Mar 10 20:01:42 PDT 2015
On Tuesday, 10 March 2015 at 22:41:32 UTC, Andrei Alexandrescu
> On 3/6/15 8:54 PM, David Soria Parra wrote:
>> 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
>> 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
>> communities and worked out well. The DIP is mostly based on
>> learned from other communities. So please go ahead:
>> 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
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.
More information about the Digitalmars-d