Incubated modules for Phobos

Piotr Szturmaj bncrbme at jadamspam.pl
Mon Dec 19 08:46:48 PST 2011


Steven Schveighoffer wrote:
> On Sun, 18 Dec 2011 10:00:35 -0500, Piotr Szturmaj
> <bncrbme at jadamspam.pl> wrote:
>
>> Peter Alexander wrote:
>>> On 18/12/11 2:18 PM, Piotr Szturmaj wrote:
>>>> "Exp" code may be shipped with each release just like "etc" code. Users
>>>> using experimental code should be aware of breaking changes that may be
>>>> introduced with each release or even with each commit.
>>>>
>>>> Thoughts?
>>>
>>> Isn't this just reinventing git branches?
>>>
>>> If people have their work-in-progress branches on GitHub then people can
>>> already try them out, submit pull requests etc. That's the whole point
>>> of a branch.
>>
>> Yes, but what I propose is the centralized repository for that
>> branches (eventual candidates to std). Currently no one knows all
>> modules that are being worked on.
>
> I think it would be enough to post something on D.announce and then
> whoever is interested can watch your branch. Maybe even a wiki page
> could categorize the branches.
>
> I agree with others that github's forking and branching mechanism works
> quite well for developing multi-user projects. For example, both Lars
> Kyllingstad and I are working on a new std.process module, he's doing
> the main design and unixen implementations, I'm doing the windows
> implementation.

Okay, I agree too. The core problem is that modules after inclusion 
become official/public instantly and API must be frozen. Eventual API 
issues discovered after the inclusion are often impossible to fix 
because nobody "likes" deprecations and breaking changes.

So, instead of making modules public from the start, I would rather give 
some additional "beta" time for them. Interested users may check out 
these modules in the "real world" during that time. Also, beta code may 
introduce breaking changes without worrying.

I think review is a requirement of course but it is often not enough. 
Some things may not be catched during review. Code must be extensively 
_used_ to prove its quality.

If you agree with me, there is only one additional rule to add to Phobos 
contribution process. After a review and voting process, add module to 
etc (or exp, whatever) for one month. Then move it to std if no/little 
changes were made during that trial. If changes are big the trial period 
should be extended.


More information about the Digitalmars-d mailing list