I suggest that in the ddoc at the top of each module, we add a section
named something like "Stability:" or "Development Status:"
This section can state anything from "Highly experimental, subject to
change without notice" to "stable, non-breaking changes only"
to "scheduled for deprecation, will be marked as deprecated in
DMD2.060 and removed in DMD 2.070. Use std.newstuff instead.".
If we do this, we can discourage users from relying too much on
unstable parts of Phobos.
(Ie, if somebody uses something marked as highly unstable, and their
code breaks, it's their problem. If it was marked as stable and it
breaks, it's our problem).

The current, rather ridiculous situation, is that we have users assuming that everything is equally stable (stifling Phobos development) or assuming that everything is equally unstable (making serious use of D2 impossible).

I think that's a good idea. I've also talked to Walter about implementing deprecated("string argument"), which would go a long way towards establishing a systematic evolution strategy.

Andrei

On 11/16/10 6:45 PM, Don Clugston wrote:
> I suggest that in the ddoc at the top of each module, we add a section
> named something like "Stability:" or "Development Status:"
> This section can state anything from "Highly experimental, subject to
> change without notice" to "stable, non-breaking changes only"
> to "scheduled for deprecation, will be marked as deprecated in
> DMD2.060 and removed in DMD 2.070. Use std.newstuff instead.".
> If we do this, we can discourage users from relying too much on
> unstable parts of Phobos.
> (Ie, if somebody uses something marked as highly unstable, and their
> code breaks, it's their problem. If it was marked as stable and it
> breaks, it's our problem).
>
> The current, rather ridiculous situation, is that we have users
> assuming that everything is equally stable (stifling Phobos
> development) or assuming that everything is equally unstable (making
> serious use of D2 impossible).
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Wed, 17 Nov 2010 03:45:10 +0100
Don Clugston <dclugston at googlemail.com> wrote:

> I suggest that in the ddoc at the top of each module, we add a section
> named something like "Stability:" or "Development Status:"
> This section can state anything from "Highly experimental, subject to
> change without notice" to "stable, non-breaking changes only"
> to "scheduled for deprecation, will be marked as deprecated in
> DMD2.060 and removed in DMD 2.070. Use std.newstuff instead.".
> If we do this, we can discourage users from relying too much on
> unstable parts of Phobos.
> (Ie, if somebody uses something marked as highly unstable, and their
> code breaks, it's their problem. If it was marked as stable and it
> breaks, it's our problem).
> 
> The current, rather ridiculous situation, is that we have users assuming that everything is equally stable (stifling Phobos development) or assuming that everything is equally unstable (making serious use of D2 impossible).


It seems necessary from a newcomer POV.

What about learning from other languages' stdlib implementation & evolution? More generally, about language development process? Python is an example in this domain (clear set of builtin features(*), 1 need <--> 1 tool(*), transition phases, deprecation warnings, PEPs...); maybe the evolution process (PEPs & 2 mailing lists) is just a bit too complicated.

For an outsider subscribed to D mailing lists, the development of D2 _seems_ a mess. It don't mean it is, actually have no idea, but to me it looks like beeing so. The development of Phobos even more.

But the biggest obstacle to D's adoption (at least D2, haven't tried D1) may be documentation. Possibly I should switch to D1 just to see if it makes a difference? TDPL is partly a great help, esp thank to explaining rationales, but:
* It addresses only the core language (not the libs).
* It introduces differences with the actual language.
* It frozes the language.
(The last point risks to be very bad in a while, imo. A language's life is a moving target, like for anything designed and highly complex. Rather let down TDPL as a dev. reference as soon as it's clear it's no more the goal, and prepare a new edition.)


Denis

(*) I mean one gets enough from the core language for most (general-purpose) programming tasks. If one has a special need (domain-specific), then there is _one_ dedicated package in the stdlib. If this tool does not fit one's expectation, then it's time to look for non-standard libs.
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

On Wed, Nov 17, 2010 at 3:13 AM, spir <denis.spir at gmail.com> wrote:

> What about learning from other languages' stdlib implementation & evolution? More generally, about language development process? Python is an example in this domain (clear set of builtin features(*), 1 need <--> 1 tool(*), transition phases, deprecation warnings, PEPs...); maybe the evolution process (PEPs & 2 mailing lists) is just a bit too complicated.

You can write up a DIP if you desire:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

It is somewhat official, and a little manual, but this is the currently accepted way to create and document a requested change for discussion and revision.

-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

On Wednesday, November 17, 2010 09:20:47 Jesse Phillips wrote:
> On Wed, Nov 17, 2010 at 3:13 AM, spir <denis.spir at gmail.com> wrote:
> > What about learning from other languages' stdlib implementation &
> > evolution? More generally, about language development process? Python is
> > an example in this domain (clear set of builtin features(*), 1 need <-->
> > 1 tool(*), transition phases, deprecation warnings, PEPs...); maybe the
> > evolution process (PEPs & 2 mailing lists) is just a bit too
> > complicated.
> 
> You can write up a DIP if you desire:
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs
> 
> It is somewhat official, and a little manual, but this is the currently accepted way to create and document a requested change for discussion and revision.

Except that it's obviously pretty much never used. There a grant total of 8 DIPs with the first one being only an example. It may very well be that we should start using DIPs as a major part of Phobos development (or something similar to DIPs rather than DIPs, since arguably DIPs are for the language itself rather than the standard library - maybe PIP (Phobos Improvement Proposal) or DLIP (D Library Improvement Proposal)), but they obviously aren't really be used at this point.

I do think that it's clear though that we need to start thinking about how to better organize and formalize some aspects of Phobos development - especially once we reach the point that we want it to be relatively stable. Right now, the whole process is very ad hoc, which has worked so far, but as we get closer to serious stability and as more people work on Phobos (be it by actually being on the dev team with commit access or by submitting bug fixes or modules for possible inclusion), it's going to need to become more organized. There isn't much with a clear process at this point, and that's going to make making real progress more difficult.

One thing that really struct me with some of the posts about Go recently and its one year birthday was how many developers they had who had submitted to the project. It was _way_ more than we have, and I get the impression that they're progressing far faster than we are. That doesn't mean that we want to do things the way that they do or have as many people contributing as they do, but the current process can't handle that kind of participation, and we are going to need more participation if we want Phobos to grow and progress faster.

- Jonathan M Davis