On Monday, 7 October 2013 at 12:01:38 UTC, Dicebot wrote:
I think that core issue with this proposal is that it stays too
far from actual Phobos development reality and described
process is just too slow :) I am in favor of longer and more
stable transitions but in 12 months even core Phobos modules
may have API tweaks (not counting breaking compiler changes
:P). It does not make much sense to go for safer module
inclusion process when core language development still stays
pretty close to bleeding edge.
I'd propose to go directly opposite way - very flexible dub
packages in special category that get reviewed on regular basis
and put onto vote once API is set in stone and used in such
form for month or so. Voting to include into this category is
unnecessary, it should be enough to simply conform certain
style guidelines. After all, main goal is to get continuously
reviewed and easily accessible module proposals.
I would like to build upon the dub idea and move phobos
completely into a dub package. With sub packages for individual
parts. With the 'released' version of it have dependencies on
stable version versions of the sub packages. We can create sub
packages for testing packages and make it dependent on an
external repository where its development is actually happening.
It shouldn't be too hard to export a full set of sources and a
library for distribution with e.g. dmd either. This also will
allow us to focus upon modularisation and removal of inter
dependency.
However this is a complete change to how we currently do it.
Another benefit is that phobos developers will be able to build
and test whole tip versions of it with dub. Although disabling
phobos inclusion by dmd may be an issue.
Because testing packages are pushed as a sub package that is not
set as a dependency for phobos itself; it still has the name e.g.
phobos:gui but it won't break code bases if its included into
phobos later on.
