subject:"D versionning"

On Sunday, July 15, 2012 22:55:40 Walter Bright wrote:
 On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
  Arguably, we've been adding too many new features (e.g. new lambda syntax
  and SIMD support), given that we're supposed to be making everything that
  we already  have work properly, but those features haven't been breaking
  changes, and presumably forcing Walter to just fix bugs wouldn't be all
  that pleasant for him.
 
 SIMD support is critical for D's mission as a systems programming language,
 and has been important in attracting some significant adoption of D.

Oh, I'm not saying that the feature isn't valuable. I'm just pointing out that 
it's adding something new rather than actually finishing all of the features 
that we're already supposed to have, and in theory, after TDPL's release, we 
were supposed to be avoiding adding new features which we didn't need to make 
all of the existing features work until we'd finished all of the features 
outlined in TDPL. And maybe it _was_ worth adding SIMD support now rather than 
later, but it goes against what we said we were doing.

- Jonathan M Davis

Re: D versionning

2012-07-16 Thread Walter Bright


On 7/15/2012 11:06 PM, Jonathan M Davis wrote:

And maybe it _was_ worth adding SIMD support now rather than
later, but it goes against what we said we were doing.


It was a leap of faith on my part, but I think events have shown that it was 
indeed worth it.

Re: D versionning

On Sunday, July 15, 2012 23:05:39 Walter Bright wrote:
 On 7/15/2012 4:34 PM, Jonathan M Davis wrote:
  It needs to stop completely.
  
  Most of the renaming of functions which has gone on has been because
  Phobos
  has been inconsistent with its naming, which makes it harder to use and
  learn. As that's sorted out (as has mostly been done), those changes will
  stop. But do you honestly expect that everything in the standard library
  is going to be frozen at some point? Is that what you're suggesting?
 
 I've had a lot of my own working D code break because of name changes in
 Phobos. This is extremely annoying. I can fully understand that it drives
 people away. It's got to stop.
 
 We could bikeshed forever about what exact spelling and casing a name should
 have. That's fine for new names. Old names should stay.
 
 Breaking things should have a very high bar. Merely a name change is not
 good enough.

Which is precisely why I was trying to get all of the name changes out of the 
way early and quickly so that we'd get the names fixed and then not having any 
more of that kind of breakage. At this point, in almost all cases (maybe even 
in all cases), when a name gets changed, it's because the function is being 
replaced by a better function. And even that kind of change is happening less 
and should eventually become quite rare. While there are a number of symbols 
currently going through the deprecation process in Phobos, not much is being 
scheduled for deprecation anymore, and most of the stuff on the deprecation 
path has already been deprecated and is approaching the point when it will be 
removed.

I understand your annoyance with the name changes, but when it was discussed, 
almost everyone in the newsgroup thought that it was worth it to make those 
changes in order to make the library more consistent. Having done that, we are 
now far more stringent about changing names.

- Jonathan M Davis

Re: D versionning


On 2012-07-16 03:06, Adam Wilson wrote:


I would like to state that I am all for waiting onr Win64; it's a huge
project and trying to do this change in the middle of it would be the
height of stupidity. However, directly after Win64 goes live I move that
we make the dual branch model the default going forward as it solves too
many long-standing community complaints to reasonably dismiss.


I see no reason why COFF/Win64 would need to affect the current release 
(ok it already has, I know). Walter don't need to push his changes 
upstream. He can either keep them locally or in his own forks (I assume 
he uses forks).


When the work is finished he can push a new branch upstream and let 
people try that for a while. Then we can merge that branch when we feel 
it's stable enough.


--
/Jacob Carlborg

Re: D versionning


On 2012-07-16 02:36, Jonathan M Davis wrote:


Arguably, we've been adding too many new features (e.g. new lambda syntax and
SIMD support), given that we're supposed to be making everything that we
already  have work properly, but those features haven't been breaking changes,
and presumably forcing Walter to just fix bugs wouldn't be all that pleasant
for him. But until we've fully implemented what we have, I think that it's
just going to slow us down to little benefit to change the release model. Once
we have, _then_ I'd love to see a release model which promotes major vs minor
releases and the like, because then we can evolve the language and library as
appropriate while still maintaining stable releases which programmers can rely
on for long periods of time without worrying about breaking changes and
whatnot.


There are lot of other things to do than fixing bugs. For example, the 
ongoing COFF/Win64 changes. I wouldn't really consider this as a new 
feature and not really as a bug fix either. Then we have Phobos, ARM and 
tools to work on as well.


--
/Jacob Carlborg

Re: D versionning


On 2012-07-16 08:00, Walter Bright wrote:


Supporting Win64 is absolutely critical for the future of D, and the
sooner we get it, the better. The COFF route is the shortest route to
doing it, and the most practical for attracting devs, which is why it's
the way we're going.


Agree.


32 bit code is dead on OSX, is dying rapidly on Linux and Windows.


No need in removing that until it cause big maintenance problems.

--
/Jacob Carlborg

Re: D versionning


On 2012-07-16 08:06, Jonathan M Davis wrote:


Oh, I'm not saying that the feature isn't valuable. I'm just pointing out that
it's adding something new rather than actually finishing all of the features
that we're already supposed to have, and in theory, after TDPL's release, we
were supposed to be avoiding adding new features which we didn't need to make
all of the existing features work until we'd finished all of the features
outlined in TDPL. And maybe it _was_ worth adding SIMD support now rather than
later, but it goes against what we said we were doing.


Yeah, and it did pop up somewhat unexpected. Sure there were a lot of 
discussion about it but in the middle of the discussions we could see 
commits adding SIMD support popping up.


--
/Jacob Carlborg

Re: D versionning

On Monday, July 16, 2012 08:48:31 RivenTheMage wrote:
 On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:
  Changing names is minute progress, and is too costly in terms
  of annoying existing users and breaking their code.
 
 Cost can be lowered - by introducing (semi-)automatic
 refactoring/upgrade mode.
 
 dmd -upgrade zzz.d
 
 Compiler can do renames (clear() - destroy()), insert
 workarounds (if needed), and so on. Easy, fast, no risk of human
 error.
 
 Of course, in certain cituations no automatic upgrade is
 possible...

If we were doing that all the time, then such a tool would be very useful, and 
it may very well be worth creating such a tool if/when D3 comes around and 
code needs to be converted, but if we continue to change names often enough 
that you really need such a tool, then we're screwing up.

Name changes _should_ be rare. We were only doing as many as we were for a 
while there, because the names in Phobos were quite inconsistent, and almost 
everyone thought that we'd be better off to fix the names and deal with the 
breakage then rather than having to deal with the bad names forever.

- Jonathan M Davis

Re: D versionning


On 2012-07-15 23:58, Walter Bright wrote:


We did do a stable release, D1, and there were plenty of complaints that
D1 did not get new features.


Yes because it was just an arbitrary release that was picked, with 
seemingly not much though behind.



Also, all the released versions of D are available for download. There
is no need to constantly download the latest if that disrupts your
projects.


Then when you hit a bug and you ask the community they say that was 
fixed in the previous release, you should always use the latest release.


--
/Jacob Carlborg

Re: D versionning

On Monday, July 16, 2012 09:25:54 Jacob Carlborg wrote:
 On 2012-07-16 02:20, Jonathan M Davis wrote:
  If someone has a better proposal, they should make it (though probably in
  a
  separate thread - this one's long enough as it is). I think that the
  basics of this proposal are good, and a lot of projects work that way. I
  just think that D needs to be more stable before we worry about having
  major and minor releases or stable and unstable branches.
 
 Wasn't that what you just said two posts up? To have major and minor
 releases. Major containing new features and minor only bug fixes.

Isn't that essentially whan the OP's proposal was? We'd have 2.x.y where x is 
for major releases and y is for minor releases, with only bug fixes being 
permitted in minor releases. I don't think that I've proposed any other 
versioning schemes than what the OP was proposing. If I did, I misunderstood 
something.

- Jonathan M Davis

Re: D versionning


On 2012-07-16 03:11, Andrei Alexandrescu wrote:


I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.


What would the difference between unstable and HEAD be?

--
/Jacob Carlborg

Re: D versionning


On 2012-07-16 03:11, Andrei Alexandrescu wrote:

On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:

1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.

If we see this works well and gathers steady interest, we can improve it
and make it the practice of the entire team.


Another idea to start with would be to create new temporary branches for 
bigger changes, i.e. COFF/Win64.


--
/Jacob Carlborg

Re: D versionning


On 2012-07-16 08:51, Walter Bright wrote:


It is a good idea, but I'd be nervous myself about allowing the compiler
to edit my code :-)


Don't you trust your own compiler :)

The compiler could have --dry-run option to show what would be changed. 
It could also show a diff after all processing.


--
/Jacob Carlborg

Re: D versionning

2012-07-16 Thread Kevin Cox

On Jul 16, 2012 4:15 AM, Jacob Carlborg d...@me.com wrote:

 On 2012-07-16 08:51, Walter Bright wrote:

 It is a good idea, but I'd be nervous myself about allowing the compiler
 to edit my code :-)


 Don't you trust your own compiler :)

 The compiler could have --dry-run option to show what would be changed.
It could also show a diff after all processing.

 --
 /Jacob Carlborg


Yeah, and if you're using some kind of version control system there is
really no risk.

Re: D versionning

2012-07-16 Thread David Nadlinger


On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:
SIMD support is critical for D's mission as a systems 
programming language, and has been important in attracting some 
significant adoption of D.


Has it?

David

Re: D versionning

2012-07-16 Thread Iain Buclaw

On 16 July 2012 12:26, David Nadlinger s...@klickverbot.at wrote:
 On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:

 SIMD support is critical for D's mission as a systems programming
 language, and has been important in attracting some significant adoption of
 D.


 Has it?

 David




It certainly raised a few eyebrows from D users from the Game
Development market.  Even had someone from Remedy Games contact me
over some support queries - which I found to be a bit of a surprise.
:-)


-- 
Iain Buclaw

*(p  e ? p++ : p) = (c  0x0f) + '0';

Re: D versionning

2012-07-16 Thread David Nadlinger


On Monday, 16 July 2012 at 11:34:26 UTC, Iain Buclaw wrote:

It certainly raised a few eyebrows from D users from the Game
Development market.


I don't doubt that, but has SIMD support in its current form 
actually led to any »significant adoption«? For example, I got 
dozens of private requests from different programmers, some from 
companies with big names, regarding Thrift support in D after 
last year's GSoC. I know that it led some people to play around 
with D, but that's hardly what I would call »significant 
adoption«…


David

Re: D versionning

2012-07-16 Thread Jesse Phillips


On Monday, 16 July 2012 at 06:05:43 UTC, Walter Bright wrote:

I've had a lot of my own working D code break because of name 
changes in Phobos. This is extremely annoying. I can fully 
understand that it drives people away. It's got to stop.


Name changes have been the least annoying breaking change I've 
come across from using D. Language design being the biggest.


Luckily I've expected that, and recently hit has been very 
infrequent. There are still changes that will be making big 
ripples (actually maybe not so much if we are changing how we 
handle toHash...). Maybe this unstable branch thing will allow us 
to make a bunch of a breaking changes together when we have one 
of these required disruptions.

On Monday, 16 July 2012 at 06:00:03 UTC, Walter Bright wrote:
Supporting Win64 is absolutely critical for the future of D,
and the sooner we get it, the better. The COFF route is the
shortest route to doing it, and the most practical for
attracting devs, which is why it's the way we're going.

Sorry, but I don't think this is a valid argument. Yes, Win64
(and even more so, COFF) support is important to have for DMD,
but no, it's not a good idea to delay a pending release because
of this (cf. the »Time for a new beta« thread from the end of
May). Here is why:

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2012-04-13bug_status=RESOLVEDresolution=FIXED

Already 289 issues resolved since 2.059!

And implementing Win64 support isn't going to be done in a
weekend. Sure, the changes needed are not world-shattering:
Finish COFF writing support, tweak the register spilling/call
emitting code to conform to the Win64 ABI, implement vararg
support in both the backend and druntime (they are handled
differently on Win64 than described in the System V ABI),
transition to the MSVC runtime. druntime and Phobos will also
require some changes, although there shouldn't be much left to
do, given that GDC (and LDC, except for exceptions) already work
on x64 Windows.

After this has been done, there are still

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Nowquery_format=advancedchfieldfrom=2012-04-13bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED

to deal with. And after those regressions have been fixed and a
first beta is released, chances are that some new regressions
will pop up, because many people can't even use Git master for
their real-world code right now.

So, all in all, I wouldn't expect a release before, say, around
mid-September. This is five months after the last release, a
delay twice as long as our usual release cycle. Several of the
bugs fixed since 2.059 were hard to work around, so I don't think
it's unreasonable to assume that we will have lost users because
of this. And what for? Chances are that we will just have _two_
semi-working targets in DMD then (structs are still broken on
x86_64 Linux/OS X/BSD w.r.t. parameter ABI and in some cases
sizing/alignment).

If you really want to make D more attractive, including for
corporate use (from what I gathered from several Thrift-related
discussions), the easiest thing to do, in my humble opinion,
would be to make the release schedule at least somewhat
predictable, to publish more or less dependable short-term
roadmaps, and most importantly, to actively communicate your
decisions on these topics – it just happens that you are D's
lead-developer-release-manager-strategist-dictator, regardless of
whether you'd prefer to fill only some of the roles.

David

Re: D versionning

2012-07-16 Thread Don Clugston


On 16/07/12 16:51, David Nadlinger wrote:

On Monday, 16 July 2012 at 06:00:03 UTC, Walter Bright wrote:

Supporting Win64 is absolutely critical for the future of D, and the
sooner we get it, the better. The COFF route is the shortest route to
doing it, and the most practical for attracting devs, which is why
it's the way we're going.


Sorry, but I don't think this is a valid argument. Yes, Win64 (and even
more so, COFF) support is important to have for DMD, but no, it's not a
good idea to delay a pending release because of this (cf. the »Time for
a new beta« thread from the end of May). Here is why:

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2012-04-13bug_status=RESOLVEDresolution=FIXED


Already 289 issues resolved since 2.059!


More than that. Of the official releases, there is no usable 64 bit DMD 
compiler on ANY platform. Some awful wrong-code bugs were still present 
in 2.059. They have been fixed for a couple of months in DMD git, but 
not in an official release.

Re: D versionning

2012-07-16 Thread Masahiro Nakagawa

On Monday, 16 July 2012 at 01:38:38 UTC, Alex Rønne Petersen 
wrote:

On 16-07-2012 03:11, Andrei Alexandrescu wrote:

On 7/15/12 7:44 PM, Adam Wilson wrote:
I should note that we use this exact model for every project 
we have
where I work and that it is been highly successful at keeping 
those five
points of tension moderated. And our users can actually get 
work done
without waiting for weeks and months because thing X is just 
plain

broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we 
find a

volunteer in the community who is:

1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks 
commits from
HEAD into two separate branches: bugfixes and unstable. It 
should be

easy to create installers etc. for those.

If we see this works well and gathers steady interest, we can 
improve it

and make it the practice of the entire team.

Would this be possible?


Andrei



I propose a slight variation:

* master: This is the 'incoming' branch. Unstable, in-dev, etc. 
It's easier this way since pull requests will usually target 
this branch and build bots will test this.
* stable: This branch contains only bug fixes to existing 
language features, and enhancements that do not in any way 
impact existing features (or break code). Should be manually 
maintained based on master.


That's it. I don't see a need for any added complexity to this 
simple model. Feel free to destroy as you see fit, though!


git-flow is the other candidate.

https://github.com/nvie/gitflow/

See more detail:

http://nvie.com/posts/a-successful-git-branching-model/

Re: D versionning


On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:

On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
Arguably, we've been adding too many new features (e.g. new 
lambda syntax and
SIMD support), given that we're supposed to be making 
everything that we
already  have work properly, but those features haven't been 
breaking changes,
and presumably forcing Walter to just fix bugs wouldn't be all 
that pleasant

for him.


SIMD support is critical for D's mission as a systems 
programming language, and has been important in attracting some 
significant adoption of D.


OTOH, if the people who were attracted end up quitting because 
the language is continuously unstable, the net effect is 
negative, because those who leave the boat won't come back.


I tend to agree that there should be a stable and a dev branch, 
with regular merges from dev -- stable when new non breaking 
features have been shown to work for a while. For instance, 
nothing prevents you to develop COFF and SIMD on the dev branch, 
and decide in 6 months to merge those features in the stable 
branch, because they've been shown to have stabilized.


In fact, it's much easier to make a roadmap this way than it is 
right now, where releases are delayed because new features don't 
work.


The 2.060 is late, very late.

Re: D versionning

2012-07-16 Thread Andrei Alexandrescu


On 7/16/12 4:37 PM, SomeDude wrote:

The 2.060 is late, very late.


Then perhaps it's worth priming dlang-stable with a 2.059 plus best of 
2.060 experimental release. Enough to only get a few essential commits 
in. It would help the project get its bearings.


Andrei

Re: D versionning

2012-07-16 Thread H. S. Teoh

On Mon, Jul 16, 2012 at 04:42:36PM -0400, Andrei Alexandrescu wrote:
 On 7/16/12 4:37 PM, SomeDude wrote:
 The 2.060 is late, very late.
 
 Then perhaps it's worth priming dlang-stable with a 2.059 plus best
 of 2.060 experimental release. Enough to only get a few essential
 commits in. It would help the project get its bearings.
[...]

+1.


T

-- 
Famous last words: I wonder what will happen if I do *this*...

Re: D versionning


On Sunday, 15 July 2012 at 23:15:29 UTC, deadalnix wrote:

On 15/07/2012 23:36, SomeDude wrote:
Well bug will be fixed for sure.

But, as explained, as new feature are also introduced, bug will 
also be introduced.


This is why stable release is never reached.


I ended up changing my mind, but only if the minor releases don't 
get distanced by the major releases, i.e if the features that 
have proven to be stabilized after a while end up being merged in 
the stable branch, i.e the stable branch is not frozen.


This way, the stable branch and the dev branch don't diverge to 
the point that there effectively become two versions of the same 
language.

Re: D versionning

2012-07-16 Thread Adam Wilson

On Mon, 16 Jul 2012 13:42:36 -0700, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:



On 7/16/12 4:37 PM, SomeDude wrote:

The 2.060 is late, very late.


Then perhaps it's worth priming dlang-stable with a 2.059 plus best of  
2.060 experimental release. Enough to only get a few essential commits  
in. It would help the project get its bearings.


Andrei


I should note that dlang-stable is currently forked from DMD-HEAD, so  
you'd have to reset it to the 2.059 tag then start merging commits,  
doable, but a lot of work.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

2012-07-16 Thread Adam Wilson

On Mon, 16 Jul 2012 13:45:10 -0700, SomeDude lovelyd...@mailmetrash.com  
wrote:



On Sunday, 15 July 2012 at 23:15:29 UTC, deadalnix wrote:

On 15/07/2012 23:36, SomeDude wrote:
Well bug will be fixed for sure.

But, as explained, as new feature are also introduced, bug will also be  
introduced.


This is why stable release is never reached.


I ended up changing my mind, but only if the minor releases don't get  
distanced by the major releases, i.e if the features that have proven to  
be stabilized after a while end up being merged in the stable branch,  
i.e the stable branch is not frozen.


This way, the stable branch and the dev branch don't diverge to the  
point that there effectively become two versions of the same language.


That is the main goal of dlang-stable. :-)

--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning


On Sunday, 15 July 2012 at 23:36:56 UTC, Patrick Stewart wrote:


100% passage of test suites do not make me more happy even a 
bit. Which is my business, of course.


What would make me happy is feature list on page describing 
milestones. And each version branched and kept stable, with 
bugfixes and *no* new features introduced.


Real question is where is D going? When will be enough with 
cramming new features down its throat each time a semi-good 
idea pops up? When will D leave beta and reach v1 ? Because D2 
is still in beta as far as I see it.


Seriously, your whining is getting tiring and will give you 
nothing.

Re: D versionning


On Monday, 16 July 2012 at 20:47:13 UTC, Adam Wilson wrote:
I ended up changing my mind, but only if the minor releases 
don't get distanced by the major releases, i.e if the features 
that have proven to be stabilized after a while end up being 
merged in the stable branch, i.e the stable branch is not 
frozen.


This way, the stable branch and the dev branch don't diverge 
to the point that there effectively become two versions of the 
same language.


That is the main goal of dlang-stable. :-)


Then I guess we agree :)

Re: D versionning


On Monday, 16 July 2012 at 14:28:45 UTC, Jesse Phillips wrote:

On Monday, 16 July 2012 at 06:05:43 UTC, Walter Bright wrote:

I've had a lot of my own working D code break because of name 
changes in Phobos. This is extremely annoying. I can fully 
understand that it drives people away. It's got to stop.


Name changes have been the least annoying breaking change I've 
come across from using D. Language design being the biggest.


Luckily I've expected that, and recently hit has been very 
infrequent. There are still changes that will be making big 
ripples (actually maybe not so much if we are changing how we 
handle toHash...). Maybe this unstable branch thing will allow 
us to make a bunch of a breaking changes together when we have 
one of these required disruptions.


I don't think the unstable branch should give you the false idea 
that you are free to make breaking changes, because in the end, 
they will be incorporated in the stable branch, breaking code, or 
the users will be stuck. So although there may be *some* breaking 
changes, they should stay relatively limited. Each breaking 
change should increment the x number in the 2.x.y scheme. So if 
the x moves too quickly, the stabe and unstable branches will 
quickly diverge to become unreconciliable.

Re: D versionning


On Monday, 16 July 2012 at 08:12:39 UTC, Jacob Carlborg wrote:

On 2012-07-16 08:51, Walter Bright wrote:

It is a good idea, but I'd be nervous myself about allowing 
the compiler

to edit my code :-)


Don't you trust your own compiler :)

The compiler could have --dry-run option to show what would be 
changed. It could also show a diff after all processing.


That's very precisely what the rename function of IDEs like 
eclipse do, BTW.

Re: D versionning

2012-07-16 Thread RivenTheMage


On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:

This way, the stable branch and the dev branch don't diverge to 
the point that there effectively become two versions of the 
same language.


I think, they should be diverging.

The stable branch should be the TDPL branch. After reaching 
point of TDPL-compliance (top priority for the branch), only 
bugfixes and non-breaking features must be accepted (like COFF 
support).


The dev branch should be the DMD3/TDPLv2 branch: a cutting edge
version of the D language.

Re: D versionning


On Monday, 16 July 2012 at 21:29:31 UTC, RivenTheMage wrote:

On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:

This way, the stable branch and the dev branch don't diverge 
to the point that there effectively become two versions of the 
same language.


I think, they should be diverging.

The stable branch should be the TDPL branch. After reaching 
point of TDPL-compliance (top priority for the branch), only 
bugfixes and non-breaking features must be accepted (like COFF 
support).


The dev branch should be the DMD3/TDPLv2 branch: a cutting 
edge

version of the D language.


I don't think so. I think it's the best way to split the 
community of users with the community of developers.

Re: D versionning

2012-07-16 Thread RivenTheMage


On Monday, 16 July 2012 at 21:29:39 UTC, SomeDude wrote:

That's very precisely what the rename function of IDEs like 
eclipse do, BTW.


The upgrade mode should be more than just textual
search-and-replace.

Re: D versionning


On Monday, 16 July 2012 at 21:34:45 UTC, RivenTheMage wrote:

On Monday, 16 July 2012 at 21:29:39 UTC, SomeDude wrote:

That's very precisely what the rename function of IDEs like 
eclipse do, BTW.


The upgrade mode should be more than just textual
search-and-replace.


It's *not* textual search and replace. It's compiler checked 
semantic refactoring.

Re: D versionning

On Monday, July 16, 2012 23:29:30 RivenTheMage wrote:
 On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:
  This way, the stable branch and the dev branch don't diverge to
  the point that there effectively become two versions of the
  same language.
 
 I think, they should be diverging.
 
 The stable branch should be the TDPL branch. After reaching
 point of TDPL-compliance (top priority for the branch), only
 bugfixes and non-breaking features must be accepted (like COFF
 support).
 
 The dev branch should be the DMD3/TDPLv2 branch: a cutting edge
 version of the D language.

We're talking about doing something similar to having 2.x.y, with the main 
branch incrementing x and the stable branch incrementing y. Going to v3 
would mean incrementing the 2. We have _no_ intention of doing that for years 
to come.

- Jonathan M Davis

Re: D versionning

2012-07-16 Thread Andrei Alexandrescu


On 7/16/12 5:33 PM, Jonathan M Davis wrote:

We're talking about doing something similar to having 2.x.y, with the main
branch incrementing x and the stable branch incrementing y.


That seems a simple, nice scheme.

Andrei

Re: D versionning

2012-07-16 Thread deadalnix


On 17/07/2012 00:33, Andrei Alexandrescu wrote:

On 7/16/12 5:33 PM, Jonathan M Davis wrote:

We're talking about doing something similar to having 2.x.y, with the
main
branch incrementing x and the stable branch incrementing y.


That seems a simple, nice scheme.

Andrei


That is the scheme proposed in the very first post. It has been used 
successfully in many projects.

Re: D versionning

2012-07-16 Thread deadalnix


On 16/07/2012 23:26, SomeDude wrote:

On Monday, 16 July 2012 at 14:28:45 UTC, Jesse Phillips wrote:

On Monday, 16 July 2012 at 06:05:43 UTC, Walter Bright wrote:


I've had a lot of my own working D code break because of name changes
in Phobos. This is extremely annoying. I can fully understand that it
drives people away. It's got to stop.


Name changes have been the least annoying breaking change I've come
across from using D. Language design being the biggest.

Luckily I've expected that, and recently hit has been very infrequent.
There are still changes that will be making big ripples (actually
maybe not so much if we are changing how we handle toHash...). Maybe
this unstable branch thing will allow us to make a bunch of a breaking
changes together when we have one of these required disruptions.


I don't think the unstable branch should give you the false idea that
you are free to make breaking changes, because in the end, they will be
incorporated in the stable branch, breaking code, or the users will be
stuck. So although there may be *some* breaking changes, they should
stay relatively limited. Each breaking change should increment the x
number in the 2.x.y scheme. So if the x moves too quickly, the stabe and
unstable branches will quickly diverge to become unreconciliable.



This is exactly the reason why the 3 digit versionning system exists.

Re: D versionning

2012-07-16 Thread Chris NS

+1 for a 2.breaking.bugfix scheme.  I've used this scheme on 
anything serious for years, and know many others who have; so it 
is not only popular but also quite tried and proven.  Not for 
every project, of course (although I don't understand why the 
Linux kernel team dropped it with 3.x), but for the majority it 
seems to work wonders.


Rest of the thread seems like so much unnecessary politic.

Re: D versionning

2012-07-16 Thread RivenTheMage


On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:


Going to v3 would mean incrementing the 2.
We have _no_ intention of doing that for years
to come.


Small steps are perfect for many projects, but - in my opinion -
not for a programming language specification (and reference 
implementation). Big leaps are better.


Look at C# - 2.0, 3.0, 4.0...

I'm aware of counterexamples (like PHP), but these are bad
examples to follow.

Re: D versionning

On Tuesday, July 17, 2012 06:37:23 RivenTheMage wrote:
 On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:
  Going to v3 would mean incrementing the 2.
  We have _no_ intention of doing that for years
  to come.
 
 Small steps are perfect for many projects, but - in my opinion -
 not for a programming language specification (and reference
 implementation). Big leaps are better.
 
 Look at C# - 2.0, 3.0, 4.0...
 
 I'm aware of counterexamples (like PHP), but these are bad
 examples to follow.

Actually, most programming languages are very conservative in how often they 
break existing code. And as I understand it (I haven't used C# much), C# 
doesn't break a lot of code either. They mostly just add more stuff on top of 
what they did before and then try and get you to use the new stuff in addition 
to the old stuff (or instead of, depending on what it is). But the old stuff is 
still there.

We'll continue to add new features to Phobos for the forseeable future as long 
as those features are worth adding. And while I don't expect that we'll add 
very many language features to D or that they'll be added very quickly, non-
breaking additions will still occur from time to time. However, _breaking_ 
changes to the language should be pretty much non-existent for _years_ to 
come, and breaking changes to Phobos should become quite rare if not non-
existent as well.

We'll eventually look at starting D3, which will mean breaking core language 
stuff where we deem appropriate and possibly completely revamping stuff in 
Phobos, but D2 needs to become fully stable and get a solid user base _long_ 
before we'll consider pulling the rug out from everyone with D3.

- Jonathan M Davis

Re: D versionning

2012-07-15 Thread captaindet


On 2012-07-14 20:42, Adam Wilson wrote:

On Sat, 14 Jul 2012 16:56:50 -0700, Walter Bright newshou...@digitalmars.com 
wrote:


On 7/13/2012 9:58 AM, Jonathan M Davis wrote:

All that being the case, I don't know what this proposal actually buys us.


I tend to agree.



If this was the case; 2.059 would not be three months old with no 2.060 in the 
immediate future.

Not having that situation is what this buys us.

I believe that there IS a problem here. There are people who, for various 
reasons, cannot use Git HEAD, and they have open problems. They are stuck. I 
believe that is the unstated impetus for this thread.


+1

pls make a fresh build available on a weekly or at least biweekly basis, just 
with regressions fixed.

Re: D versionning


On 15/07/2012 01:56, Walter Bright wrote:

On 7/13/2012 9:58 AM, Jonathan M Davis wrote:

All that being the case, I don't know what this proposal actually buys
us.


I tend to agree.



After 10 years of D, nothing stable still exists. We may call 2.059 
stable, but frankly, it isn't.


This have a lot to do with the fact that new feature are included (with 
news bugs) in the same stream of version than bug fixes. In other terms, 
bug are fixed but at the same time, bugs are added with new features.


The natural result is that D is not stable yet, and never will be as 
long as the same process is used.


The proposed versioning system solve that problem. It doesn't matter if 
that very system is chosen in fact, but the current one is certainly not 
the one D needs.

Re: D versionning

There is one thing missing from developers perspective as far D is concerned: 
Not all D users want to be beta testers. But they are all treated in such a way.

That is reason #1 I migrate away from D all my software. It is long process and 
tough decision, but after 5 years of tracking D story I am fed up and I see 
nothing has changed and it will probably stay like that in foreseeable future.

Re: D versionning

2012-07-15 Thread SomeDude


On Thursday, 12 July 2012 at 17:20:32 UTC, deadalnix wrote:

On 12/07/2012 19:10, Tobias Pankrath wrote:
The system adopted in PHP works with a 3 number version. The 
first
number is used for major languages changes (for instance 4  
5 imply
passing object by reference when it was by copy before, 5  6 
switched

the whole thing to unicode).

The second number imply language changes, but either non 
breaking or

very specific, rarely used stuff. For instance 5.2
 5.3 added GC, closures and namespace which does not break
code.



We can also learn from the python community, whose from 
__future__
import feature facility is a great success and we should 
adopt a

similar scheme.

Consider the -property switch or a future introduction of 
tuple syntax.
If you start a new project, it's no problem. Just use the 
switch and don't
introduce things that will not work without. But if you have 
an old

codebase
but want to use a new feature you can either

a) fix the hole codebase at one
b) fix and configure your build systems to build some files 
with and

some files without the switch.

Both options are PITA. An alternative is to introduce 
#pragma(future,

tuplesyntax);

Now you can insert the pragma in those sourcefiles that are 
new or
already fixed and you can immediately benefit from the feature 
and you

can upgrade your code file by file or even scope by scope.

Later versions could even introduce #pragma(past, 
notuplesyntax) before

dropping the old syntax completely.



This scheme don't allow for breaking change to be made. It also 
require the compiler to handle a mess of features that can be 
activated or not. This is way more work, and I don't really see 
the benefice.


As non breaking change are introduced in a different process 
than breaking one, it is easy to migrate to new version that 
will not break legacy code and provide new features.


OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.

Re: D versionning

 OTOH, it may break the community yet again, which we certainly 
 don't want, probably even less than breaking code.
 Also, the example of Python with two main stable branches that 
 live in parallel is not very encouraging.

Are you kidding? Python should be used as example of how software should be 
engineered. They keep release schedules, keep stable versions  never break 
backward compatibility without giving their users ways to not be stuck in bad 
situation. It is well thought and planned. Its popularity and widespread is not 
a coincidence,  and the fact that it became de facto part of linuxes (shipping 
with 5 year old versions without a fear of deprecation) just proves people can 
count on it and use it without fear of some random unguided development that is 
typical of D with its half thought our new features that bite it on the ass 
year later.

Re: D versionning

 OTOH, it may break the community yet again, which we certainly 
 don't want, probably even less than breaking code.
 Also, the example of Python with two main stable branches that 
 live in parallel is not very encouraging.

Also, check Python website: they recommend python v2 for all new users that 
don't know what to choose. They are both stable, but v2 has more libraries, and 
they do reassure them by saying v2 will be supported for time to come.

On the other hand, on D website, D1 is pushed to the dark corners as ugly half 
child nobody should know about, and D2 is titled as thing to chose without 
thinking. And there is no mentioning D1 is relatively stable, while D2 is still 
unstable, non conforming to D documentation and that some things just don't 
work, while in constant beta flux that breaks things on regular basis with each 
release.

So tell me again, which language treats its users with more respect ? Which one 
encourages users more to use them?

Re: D versionning

2012-07-15 Thread SomeDude


On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.


Are you kidding? Python should be used as example of how 
software should be engineered. They keep release schedules, 
keep stable versions  never break backward compatibility 
without giving their users ways to not be stuck in bad 
situation. It is well thought and planned. Its popularity and 
widespread is not a coincidence,  and the fact that it became 
de facto part of linuxes (shipping with 5 year old versions 
without a fear of deprecation) just proves people can count on 
it and use it without fear of some random unguided development 
that is typical of D with its half thought our new features 
that bite it on the ass year later.


I understand your gripe with breaking changes and bugs, but your 
painting of the sate of things is caricatural. First Linuxes are 
not shipping with 5 year old versions of Python, they usually 
ship with 2.7 which is the last version of the 2 branch. 
Meanwhile, the 3 branch is having a hard time getting used, 
several years after its introduction, and some major packages 
still haven't been ported.

http://wiki.python.org/moin/Python2orPython3
That is what I was referring to.

I agree the Python roadmap is better paved than the D roadmap, 
which hardly exists. It does make a case for a dev and a stable 
branch, which makes complete sense. OTOH, Python has suffered 
from disruptive changes just as much as D, like the fact that 
incorporating UTF in the language has justified a completely new 
branch. And talking about half assed features, its reference 
implementation suffers from *major* issues, like being slow 
(about 5 times slower than the Pypy JIT implementation) and 
monothreaded. And that is not going to be fixed any time soon. 
And you can't use PyPy for most serious web projects as native 
libraries are not compatible and haven't been ported.

Re: D versionning

2012-07-15 Thread SomeDude


On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all 
new users that don't know what to choose. They are both stable, 
but v2 has more libraries, and they do reassure them by saying 
v2 will be supported for time to come.


On the other hand, on D website, D1 is pushed to the dark 
corners as ugly half child nobody should know about, and D2 is 
titled as thing to chose without thinking. And there is no 
mentioning D1 is relatively stable, while D2 is still unstable, 
non conforming to D documentation and that some things just 
don't work, while in constant beta flux that breaks things on 
regular basis with each release.


So tell me again, which language treats its users with more 
respect ? Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem 
of community. The D community is a tiny fraction of the Python 
community. It has been steadily growing this last year and a half 
or so, but it's still fragile. The D1/D2 split basically set it 
back to near zero for several years, with many people leaving, 
only a few staying, and a number recently coming back.


The project certainly can't afford yet another split, or many key 
people will simply throw the towel. I for one would rather see 
part of the users quitting than active members.


As for the stability of D2, upir opinion may be different, but it 
has largely improved recently due to increased forces, as several 
people have noted (David Simcha in a recent thread said something 
about the stability of the compiler being good enough that he 
only rarely encountered a problem). And considering the rate of 
bugs correction, it will continue to improve. You only need to 
have a look at the changelog to see that it's growing with each 
release, and I'm pretty confident that the 2.060 will contain 
more bug fixes than any past release.

Re: D versionning

On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude lovelyd...@mailmetrash.com  
wrote:



On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly don't  
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in  
parallel is not very encouraging.


Are you kidding? Python should be used as example of how software  
should be engineered. They keep release schedules, keep stable versions  
 never break backward compatibility without giving their users ways to  
not be stuck in bad situation. It is well thought and planned. Its  
popularity and widespread is not a coincidence,  and the fact that it  
became de facto part of linuxes (shipping with 5 year old versions  
without a fear of deprecation) just proves people can count on it and  
use it without fear of some random unguided development that is typical  
of D with its half thought our new features that bite it on the ass  
year later.


I understand your gripe with breaking changes and bugs, but your  
painting of the sate of things is caricatural. First Linuxes are not  
shipping with 5 year old versions of Python, they usually ship with 2.7  
which is the last version of the 2 branch. Meanwhile, the 3 branch is  
having a hard time getting used, several years after its introduction,  
and some major packages still haven't been ported.

http://wiki.python.org/moin/Python2orPython3
That is what I was referring to.

I agree the Python roadmap is better paved than the D roadmap, which  
hardly exists. It does make a case for a dev and a stable branch, which  
makes complete sense. OTOH, Python has suffered from disruptive changes  
just as much as D, like the fact that incorporating UTF in the language  
has justified a completely new branch. And talking about half assed  
features, its reference implementation suffers from *major* issues, like  
being slow (about 5 times slower than the Pypy JIT implementation) and  
monothreaded. And that is not going to be fixed any time soon. And you  
can't use PyPy for most serious web projects as native libraries are not  
compatible and haven't been ported.


To be fair, the majority of the problems you listed with Python have  
nothing to do with their release process but their design process. The two  
are unrelated. The fact that it suffers disruptive changes is an argument  
for dev/stable branches, not against.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning


On 7/12/2012 3:40 PM, Patrick Stewart wrote:

Most ridiculous thing about D is that it breaks so much backward compatibility 
that people just give up using it. Decent versioning like this might help 
people stick to something.

Wake up, guys, it is 10+ years and *still* it haven't reached some form of 
stable release.

Like I sad, engineering failure.



We did do a stable release, D1, and there were plenty of complaints that D1 did 
not get new features.


Also, all the released versions of D are available for download. There is no 
need to constantly download the latest if that disrupts your projects.

Re: D versionning

On Sun, 15 Jul 2012 14:36:06 -0700, SomeDude lovelyd...@mailmetrash.com  
wrote:



On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly don't  
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in  
parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all new users  
that don't know what to choose. They are both stable, but v2 has more  
libraries, and they do reassure them by saying v2 will be supported for  
time to come.


On the other hand, on D website, D1 is pushed to the dark corners as  
ugly half child nobody should know about, and D2 is titled as thing to  
chose without thinking. And there is no mentioning D1 is relatively  
stable, while D2 is still unstable, non conforming to D documentation  
and that some things just don't work, while in constant beta flux that  
breaks things on regular basis with each release.


So tell me again, which language treats its users with more respect ?  
Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem of  
community. The D community is a tiny fraction of the Python community.  
It has been steadily growing this last year and a half or so, but it's  
still fragile. The D1/D2 split basically set it back to near zero for  
several years, with many people leaving, only a few staying, and a  
number recently coming back.


The project certainly can't afford yet another split, or many key people  
will simply throw the towel. I for one would rather see part of the  
users quitting than active members.


As for the stability of D2, upir opinion may be different, but it has  
largely improved recently due to increased forces, as several people  
have noted (David Simcha in a recent thread said something about the  
stability of the compiler being good enough that he only rarely  
encountered a problem). And considering the rate of bugs correction, it  
will continue to improve. You only need to have a look at the changelog  
to see that it's growing with each release, and I'm pretty confident  
that the 2.060 will contain more bug fixes than any past release.


You are concerned that adopting an OSS best-practice is going to split the  
community ... seriously? I find that a very hard argument to swallow with  
a straight face. We aren't splitting D2 into a D3, are simply arguing for  
a bugfix branch (stable) and a new feature branch (dev). How, pray tell,  
is this a split? We are merely seeking to make two things that are  
logically unrelated, bugs and new features, and make them physically  
unrelated as well.


The idea that bugs and new features can and should be rolled into the same  
release runs counter to every accepted best practice in both FOSS and  
Commercial wisdom. The two have VERY different velocities, bugs can be  
fixed in days, but new features take much longer. Consider COFF support  
for example, Walter has been hammering away at it for weeks now, and he  
isn't even 50% done, how many bugs have been fixed and confirmed resolved,  
in the same timespan? Also, consider that adding new features makes it  
significantly harder to track down regressions (is a real regression or  
did the new feature upset the code in an unexpected way) and the new  
features themselves create new bugs. If the branches are separate then it  
becomes trivial to determine if the new feature caused the bug, because it  
will show up in one and not the other.


How DARE we DEMAND that our users wait 4 MONTHS for regression fixes  
because we are afraid of a split or a little extra work? How many users  
could we lose if we significantly slowed down the release cycle (and  
therefore the bugfix cycle) such that people are waiting many months for  
their fixes? The language would be perceived as dead/dying and that would  
be just as bad as the D1/D2 split. If you allow your past experiences to  
paralyze you into inaction, you will bring about the very problem you seek  
to avoid.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

On Sun, 15 Jul 2012 14:58:14 -0700, Walter Bright  
newshou...@digitalmars.com wrote:



On 7/12/2012 3:40 PM, Patrick Stewart wrote:
Most ridiculous thing about D is that it breaks so much backward  
compatibility that people just give up using it. Decent versioning like  
this might help people stick to something.


Wake up, guys, it is 10+ years and *still* it haven't reached some form  
of stable release.


Like I sad, engineering failure.



We did do a stable release, D1, and there were plenty of complaints that  
D1 did not get new features.


Also, all the released versions of D are available for download. There  
is no need to constantly download the latest if that disrupts your  
projects.




And with the comming deprecation of D1, what then?

Going backwards is almost never the answer with D2, the bugs are almost  
always still there.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

On Sunday, July 15, 2012 14:58:14 Walter Bright wrote:
 On 7/12/2012 3:40 PM, Patrick Stewart wrote:
  Most ridiculous thing about D is that it breaks so much backward
  compatibility that people just give up using it. Decent versioning like
  this might help people stick to something.
  
  Wake up, guys, it is 10+ years and *still* it haven't reached some form of
  stable release.
  
  Like I sad, engineering failure.
 
 We did do a stable release, D1, and there were plenty of complaints that D1
 did not get new features.

Well, if we were to move to a model where we had 2.x.y, we only put new 
features on changes to x, and bug fixes when in changes to y, and we did x 
releases every few months and y releases monthly (or something along those 
lines), then people would theoretically get a more stable release to work off 
of with the new features still coming semi-frequently. You get a better 
balance between stability and new stuff than we've had. And I think that in the 
long run, that's probably what we should do. Instead, what we've had is either 
stability without any new features or at all or a new features but a lack of 
stabliity.

The problem is that we're still ironing out too much, and most of the breakage 
relates to bug fixes, not new features. I think that we need to reach the point 
where D is more or less at where TDPL says it should be before we go to a 
model we're splitting out the new stuff from the bug fixes. In theory, the only 
new stuff that we're doing right now relates to matching TDPL and ironing out 
issues with existing stuff rather than outright adding new features anyway 
(though some outright new stuff _has_ been added - e.g. the new lambda syntax). 
So, in that sense, pretty much everything is supposed to be bug fixing right 
now.

- Jonathan M Davis

Re: D versionning


On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the breakage
relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming library 
functions.

Re: D versionning


On 7/15/2012 3:00 PM, Adam Wilson wrote:

Also, all the released versions of D are available for download. There is no
need to constantly download the latest if that disrupts your projects.



And with the comming deprecation of D1, what then?


It'll still be there for download for those that want to use it.



Going backwards is almost never the answer with D2, the bugs are almost always
still there.


To me, 'stable' means unchanging, not 'has no bugs'.

Re: D versionning


On 7/14/2012 6:42 PM, Adam Wilson wrote:

I believe that there IS a problem here. There are people who, for various
reasons, cannot use Git HEAD, and they have open problems. They are stuck. I
believe that is the unstated impetus for this thread.


There is no answer to:

Do not change things, but change everything.

Re: D versionning


On 7/15/2012 10:25 AM, captaindet wrote:

pls make a fresh build available on a weekly or at least biweekly basis, just
with regressions fixed.


2.059 had only 3 outstanding regressions.

Re: D versionning

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
 On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
  The problem is that we're still ironing out too much, and most of the
  breakage relates to bug fixes, not new features.
 
 There's been a lot of non-bug-fixing breakage, for example, renaming library
 functions.

Yeah, but those are always done through a deprecation path, so there's no 
immediate breakage. And we've done most of that already, so that should be 
happening less and less.

However, if we did move to a model where we had major and minor releases, then 
deprecating and removing functions would presumably be restricted to major 
releases.

- Jonathan M Davis

Re: D versionning

On Sun, 15 Jul 2012 15:32:06 -0700, Walter Bright  
newshou...@digitalmars.com wrote:



On 7/15/2012 3:00 PM, Adam Wilson wrote:
Also, all the released versions of D are available for download. There  
is no

need to constantly download the latest if that disrupts your projects.



And with the comming deprecation of D1, what then?


It'll still be there for download for those that want to use it.



I guess my point is that at that time we only have one operative branch  
per your implication. Great, it's still there, but it's un


Going backwards is almost never the answer with D2, the bugs are almost  
always

still there.


To me, 'stable' means unchanging, not 'has no bugs'.



So the problem is semantics then? Because I dredge up another word to  
describe what we are asking for if that's all it takes. But I don't think  
that anyone else is going to read stable as unchanging. Software is by  
definition changing, or it's dead. It appears to my parsing of your  
sentence that you are asserting that stable == static. By that definition  
of stable, Windows ME is stable and ... ehrm, not a soul in the tech  
world would agree with that summation of WinME.


As I said earlier, no one else in FOSS or Commercial equates stable with  
has no bugs, it means no new features and no regressions. Not a single  
solitary person I've talked too expects their software to be bug free.


THIS is what we mean when we say stable:  
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

It's also how pretty much everyone else will read stable.

--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

Adam Wilson Wrote:

 On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude lovelyd...@mailmetrash.com  
 wrote:
 
  On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
  OTOH, it may break the community yet again, which we certainly don't  
  want, probably even less than breaking code.
  Also, the example of Python with two main stable branches that live in  
  parallel is not very encouraging.
 
  Are you kidding? Python should be used as example of how software  
  should be engineered. They keep release schedules, keep stable versions  
   never break backward compatibility without giving their users ways to  
  not be stuck in bad situation. It is well thought and planned. Its  
  popularity and widespread is not a coincidence,  and the fact that it  
  became de facto part of linuxes (shipping with 5 year old versions  
  without a fear of deprecation) just proves people can count on it and  
  use it without fear of some random unguided development that is typical  
  of D with its half thought our new features that bite it on the ass  
  year later.
 
  I understand your gripe with breaking changes and bugs, but your  
  painting of the sate of things is caricatural. First Linuxes are not  
  shipping with 5 year old versions of Python, they usually ship with 2.7  
  which is the last version of the 2 branch. Meanwhile, the 3 branch is  
  having a hard time getting used, several years after its introduction,  
  and some major packages still haven't been ported.
  http://wiki.python.org/moin/Python2orPython3
  That is what I was referring to.
 
  I agree the Python roadmap is better paved than the D roadmap, which  
  hardly exists. It does make a case for a dev and a stable branch, which  
  makes complete sense. OTOH, Python has suffered from disruptive changes  
  just as much as D, like the fact that incorporating UTF in the language  
  has justified a completely new branch. And talking about half assed  
  features, its reference implementation suffers from *major* issues, like  
  being slow (about 5 times slower than the Pypy JIT implementation) and  
  monothreaded. And that is not going to be fixed any time soon. And you  
  can't use PyPy for most serious web projects as native libraries are not  
  compatible and haven't been ported.
 
 To be fair, the majority of the problems you listed with Python have  
 nothing to do with their release process but their design process. The two  
 are unrelated. The fact that it suffers disruptive changes is an argument  
 for dev/stable branches, not against.
 

Point here is how community is handling problems. It is matter of engineering 
skill, not programming. Both languages have programming bugs and bad decisions. 
Python fix them without disrupting schedule and usability. D says suck it up 
for next X years while we fix it or You have some obscure 4 year old version 
without that bug.

 -- 
 Adam Wilson
 IRC: LightBender
 Project Coordinator
 The Horizon Project
 http://www.thehorizonproject.org/

Re: D versionning


On 7/15/2012 3:43 PM, Jonathan M Davis wrote:

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:

On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the
breakage relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming library
functions.


Yeah, but those are always done through a deprecation path, so there's no
immediate breakage. And we've done most of that already, so that should be
happening less and less.


It needs to stop completely.

Re: D versionning


On 7/15/2012 3:52 PM, Adam Wilson wrote:

So the problem is semantics then? Because I dredge up another word to describe
what we are asking for if that's all it takes. But I don't think that anyone
else is going to read stable as unchanging. Software is by definition
changing, or it's dead. It appears to my parsing of your sentence that you are
asserting that stable == static. By that definition of stable, Windows ME is
stable and ... ehrm, not a soul in the tech world would agree with that
summation of WinME.

As I said earlier, no one else in FOSS or Commercial equates stable with has no
bugs, it means no new features and no regressions. Not a single solitary person
I've talked too expects their software to be bug free.

THIS is what we mean when we say stable:
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read stable.


D does have a test suite, and it is a (almost always achieved) goal to keep it 
always passing, even on the dev branch. In fact, most of my work is running the 
test suite and making sure each change doesn't regress. (Regressions that do 
slip through were not in the test suite.)


Frankly, I don't know how to do what you're asking for. D users, every single 
day, clamor for:


1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!

And, to reiterate, we did release D1. Since its release, it has only received 
bug fixes. No breaking changes, no regressions. This, inevitably, has made many 
D1 users unhappy - they wanted new features folded in.


So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all these 
mutually contradictory requests.

Re: D versionning

SomeDude Wrote:

 On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
  OTOH, it may break the community yet again, which we certainly 
  don't want, probably even less than breaking code.
  Also, the example of Python with two main stable branches that 
  live in parallel is not very encouraging.
 
  Are you kidding? Python should be used as example of how 
  software should be engineered. They keep release schedules, 
  keep stable versions  never break backward compatibility 
  without giving their users ways to not be stuck in bad 
  situation. It is well thought and planned. Its popularity and 
  widespread is not a coincidence,  and the fact that it became 
  de facto part of linuxes (shipping with 5 year old versions 
  without a fear of deprecation) just proves people can count on 
  it and use it without fear of some random unguided development 
  that is typical of D with its half thought our new features 
  that bite it on the ass year later.
 
 I understand your gripe with breaking changes and bugs, but your 
 painting of the sate of things is caricatural. First Linuxes are 
 not shipping with 5 year old versions of Python, they usually 
 ship with 2.7 which is the last version of the 2 branch. 
 Meanwhile, the 3 branch is having a hard time getting used, 
 several years after its introduction, and some major packages 
 still haven't been ported.
 http://wiki.python.org/moin/Python2orPython3
 That is what I was referring to.
 

CentOS 6.x (latest) is shiping with 2 year old python version. Most production 
servers I maintain are 4.x - 5.x with Python 2.4+ that are around 5 year old 
releases. Upgrading is not an option for most situations. And we are talking 
here about linux distro that targets stability above all.

 I agree the Python roadmap is better paved than the D roadmap, 
 which hardly exists. It does make a case for a dev and a stable 
 branch, which makes complete sense. OTOH, Python has suffered 

It goes other way around. Stability is achieved by branching development from 
trunk on certain milestones. Whole D development is one constant trunk with 
added bugs and broken backward compatibility with each release.

 from disruptive changes just as much as D, like the fact that 
 incorporating UTF in the language has justified a completely new 
 branch. And talking about half assed features, its reference 
 implementation suffers from *major* issues, like being slow 
 (about 5 times slower than the Pypy JIT implementation) and 
 monothreaded. And that is not going to be fixed any time soon. 
 And you can't use PyPy for most serious web projects as native 
 libraries are not compatible and haven't been ported.

Web projects? Speed? PyPy? You are so far up premature optimization story that 
you miss what we are talking here about.

Second biggest flaw with D development is premature optimization opsession by 
large number of devs. We haven't make it work quite yet as specs define, but 
lets us optimize it, so it can work incorrectly even faster!

Re: D versionning


On 7/12/2012 11:52 PM, Adam Wilson wrote:

I hope Walter isn't against this, because I'm not seeing much community
disagreement with this...



Note this: http://d.puremagic.com/test-results/

I don't see how what we're doing is so broken.

Re: D versionning

2012-07-15 Thread bearophile


Patrick Stewart:

Both languages have programming bugs and bad decisions. Python 
fix them without disrupting schedule and usability. D says 
suck it up for next X years while we fix it or You have some 
obscure 4 year old version without that bug.


Python C interpreter is also far simpler than designing a new 
system language, and writing its compiler and standard library. 
And behind Python there are far more developers and users.


Bye,
bearophile

Re: D versionning


On 15/07/2012 23:36, SomeDude wrote:

On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:

OTOH, it may break the community yet again, which we certainly don't
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live
in parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all new users
that don't know what to choose. They are both stable, but v2 has more
libraries, and they do reassure them by saying v2 will be supported
for time to come.

On the other hand, on D website, D1 is pushed to the dark corners as
ugly half child nobody should know about, and D2 is titled as thing to
chose without thinking. And there is no mentioning D1 is relatively
stable, while D2 is still unstable, non conforming to D documentation
and that some things just don't work, while in constant beta flux that
breaks things on regular basis with each release.

So tell me again, which language treats its users with more respect ?
Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem of
community. The D community is a tiny fraction of the Python community.
It has been steadily growing this last year and a half or so, but it's
still fragile. The D1/D2 split basically set it back to near zero for
several years, with many people leaving, only a few staying, and a
number recently coming back.

The project certainly can't afford yet another split, or many key people
will simply throw the towel. I for one would rather see part of the
users quitting than active members.

As for the stability of D2, upir opinion may be different, but it has
largely improved recently due to increased forces, as several people
have noted (David Simcha in a recent thread said something about the
stability of the compiler being good enough that he only rarely
encountered a problem). And considering the rate of bugs correction, it
will continue to improve. You only need to have a look at the changelog
to see that it's growing with each release, and I'm pretty confident
that the 2.060 will contain more bug fixes than any past release.


Well bug will be fixed for sure.

But, as explained, as new feature are also introduced, bug will also be 
introduced.


This is why stable release is never reached.

Re: D versionning

bearophile Wrote:

 Patrick Stewart:
 
  Both languages have programming bugs and bad decisions. Python 
  fix them without disrupting schedule and usability. D says 
  suck it up for next X years while we fix it or You have some 
  obscure 4 year old version without that bug.
 
 Python C interpreter is also far simpler than designing a new 
 system language, and writing its compiler and standard library. 
 And behind Python there are far more developers and users.
 
 Bye,
 bearophile

We are coming back to dsource  Tango graveyard story. D had equally capable 
and large community to. Its resources got wasted. People left. Huge amount of 
work just wasted for nothing. On the other hand, Python has one of the largest 
*operational* standard library and tons of 3rd party ones. Why? Because with 
stable language, all those libraries stayed in the game.

Re: D versionning


On 7/15/2012 4:15 PM, Patrick Stewart wrote:

We are coming back to dsource  Tango graveyard story. D had equally capable
and large community to. Its resources got wasted. People left. Huge amount of
work just wasted for nothing. On the other hand, Python has one of the
largest *operational* standard library and tons of 3rd party ones. Why?
Because with stable language, all those libraries stayed in the game.



Quite a bit of Tango has moved into D2, the parts whose authors had the rights 
to change the license and so move it.

Re: D versionning


On 7/15/2012 4:08 PM, Patrick Stewart wrote:

Second biggest flaw with D development is premature optimization opsession by
large number of devs. We haven't make it work quite yet as specs define, but
lets us optimize it, so it can work incorrectly even faster!


All versions pass the D test suite 100%. Any regressions that appeared were not 
in the test suite, but do get added as they are fixed.

Re: D versionning


On 7/15/2012 2:58 PM, Adam Wilson wrote:

The idea that bugs and new features can and should be rolled into the same
release runs counter to every accepted best practice in both FOSS and Commercial
wisdom. The two have VERY different velocities, bugs can be fixed in days, but
new features take much longer. Consider COFF support for example, Walter has
been hammering away at it for weeks now, and he isn't even 50% done, how many
bugs have been fixed and confirmed resolved, in the same timespan?


Weeks is an exaggeration. And still, there have been a steady accumulation of 
fixes.


Also,
consider that adding new features makes it significantly harder to track down
regressions (is a real regression or did the new feature upset the code in an
unexpected way) and the new features themselves create new bugs. If the branches
are separate then it becomes trivial to determine if the new feature caused the
bug, because it will show up in one and not the other.

How DARE we DEMAND that our users wait 4 MONTHS for regression fixes because we
are afraid of a split or a little extra work? How many users could we lose if we
significantly slowed down the release cycle (and therefore the bugfix cycle)
such that people are waiting many months for their fixes? The language would be
perceived as dead/dying and that would be just as bad as the D1/D2 split. If you
allow your past experiences to paralyze you into inaction, you will bring about
the very problem you seek to avoid.


Sigh. Half say we release too often, the other half not often enough.

Re: D versionning

On Sunday, July 15, 2012 16:07:40 Walter Bright wrote:
 On 7/15/2012 3:43 PM, Jonathan M Davis wrote:
  On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
  On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
  The problem is that we're still ironing out too much, and most of the
  breakage relates to bug fixes, not new features.
  
  There's been a lot of non-bug-fixing breakage, for example, renaming
  library functions.
  
  Yeah, but those are always done through a deprecation path, so there's no
  immediate breakage. And we've done most of that already, so that should be
  happening less and less.
 
 It needs to stop completely.

Most of the renaming of functions which has gone on has been because Phobos 
has been inconsistent with its naming, which makes it harder to use and learn. 
As that's sorted out (as has mostly been done), those changes will stop. But 
do you honestly expect that everything in the standard library is going to be 
frozen at some point? Is that what you're suggesting?

If we figure out that function X really should be replaced, we should be able 
to replace it. If we come up with a way better design for a module, we should 
be able to replace it. That may mean leaving the old version around for a long 
period of time, but we shouldn't be stuck for bad design decisions 
permanently. That's actually one area where having major and minor releases 
(in addition to D1 vs D2 vs D3 etc) can really help, because then you restrict 
the larger changes to the major releases. Major libraries do this all the time 
(e.g. Qt).

We definitely want to be more stable than we have been, and we want to reach 
the point where there are no longer any minor changes for naming and whatnot 
(and we're getting there), but if you want to freeze the API on Phobos 
permanently, making it so that we can only ever have additive changes, then 
there are going to be a number of people who are going to be very unhappy. In 
the long run, breaking changes should be better managed (e.g. restricted to 
only certain releases) and much rarer, but they still need to be able to 
happen.

- Jonathan M Davis

Re: D versionning

On Sun, 15 Jul 2012 16:26:50 -0700, Walter Bright  
newshou...@digitalmars.com wrote:



On 7/15/2012 2:58 PM, Adam Wilson wrote:
The idea that bugs and new features can and should be rolled into the  
same
release runs counter to every accepted best practice in both FOSS and  
Commercial
wisdom. The two have VERY different velocities, bugs can be fixed in  
days, but
new features take much longer. Consider COFF support for example,  
Walter has
been hammering away at it for weeks now, and he isn't even 50% done,  
how many

bugs have been fixed and confirmed resolved, in the same timespan?


Weeks is an exaggeration. And still, there have been a steady  
accumulation of fixes.



Also,
consider that adding new features makes it significantly harder to  
track down
regressions (is a real regression or did the new feature upset the code  
in an
unexpected way) and the new features themselves create new bugs. If the  
branches
are separate then it becomes trivial to determine if the new feature  
caused the

bug, because it will show up in one and not the other.

How DARE we DEMAND that our users wait 4 MONTHS for regression fixes  
because we
are afraid of a split or a little extra work? How many users could we  
lose if we
significantly slowed down the release cycle (and therefore the bugfix  
cycle)
such that people are waiting many months for their fixes? The language  
would be
perceived as dead/dying and that would be just as bad as the D1/D2  
split. If you
allow your past experiences to paralyze you into inaction, you will  
bring about

the very problem you seek to avoid.


Sigh. Half say we release too often, the other half not often enough.



This would solve both complaints overnight. The half that say not often  
enough have critical bugfixes they are waiting on, the too often camp  
has new things that they want now (ex. COFF) and see all this bugfixing as  
getting in the way. I agree its a problem, but this makes both happy. The  
new feature camp can use dev and put up with the breakages (what we do  
now), and bugfix camp can get back to work.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

Walter Bright Wrote:

 On 7/15/2012 4:08 PM, Patrick Stewart wrote:
  Second biggest flaw with D development is premature optimization opsession 
  by
  large number of devs. We haven't make it work quite yet as specs define, 
  but
  lets us optimize it, so it can work incorrectly even faster!
 
 All versions pass the D test suite 100%. Any regressions that appeared were 
 not 
 in the test suite, but do get added as they are fixed.
 
 

100% passage of test suites do not make me more happy even a bit. Which is my 
business, of course.

What would make me happy is feature list on page describing milestones. And 
each version branched and kept stable, with bugfixes and *no* new features 
introduced.

Real question is where is D going? When will be enough with cramming new 
features down its throat each time a semi-good idea pops up? When will D leave 
beta and reach v1 ? Because D2 is still in beta as far as I see it.

Re: D versionning

On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
 Sigh. Half say we release too often, the other half not often enough.

Which is actually one argument for going to a model where you have frequent 
minor releases which only contain bug fixes and less frequent major releases 
with the larger changes. You can never make everyone happy, but by doing so, 
you get the bug fixes faster for the folks complaining about the lack of 
frequent releases, and you get increased stability as far as the new stuff 
goes, because it doesn't come with every release.

I'm only against the proposed versioning scheme because I think that we need 
to stabilize things better (e.g. actually have all of the features that TDPL 
lists fully implemented) before we move to it. But I fully support moving to 
this sort of scheme in the long run. It manages change much better, and I 
think that many, many existing projects have shown that it promotes stable 
code bases while still allowing for them to evolve as necessary.

- Jonathan M Davis

Re: D versionning

bearophile Wrote:

 Patrick Stewart:
 
  Both languages have programming bugs and bad decisions. Python 
  fix them without disrupting schedule and usability. D says 
  suck it up for next X years while we fix it or You have some 
  obscure 4 year old version without that bug.
 
 Python C interpreter is also far simpler than designing a new 
 system language, and writing its compiler and standard library. 

Simpler - true. But having more complex problem to solve just makes more 
important to have *better* organization. And D community approach is of weekend 
developers that discovered VCS  test suite, but know nothing about branching 
and project planning.

 And behind Python there are far more developers and users.
 

Completely not relevant. Number of developers have nothing to do with project 
organization. There is a lot of software there equal or more complex that are 
product of just a few or even single programmer.

Re: D versionning

On Sun, 15 Jul 2012 16:06:58 -0700, Walter Bright  
newshou...@digitalmars.com wrote:



On 7/15/2012 3:52 PM, Adam Wilson wrote:
So the problem is semantics then? Because I dredge up another word to  
describe
what we are asking for if that's all it takes. But I don't think that  
anyone
else is going to read stable as unchanging. Software is by  
definition
changing, or it's dead. It appears to my parsing of your sentence that  
you are
asserting that stable == static. By that definition of stable, Windows  
ME is
stable and ... ehrm, not a soul in the tech world would agree with  
that

summation of WinME.

As I said earlier, no one else in FOSS or Commercial equates stable  
with has no
bugs, it means no new features and no regressions. Not a single  
solitary person

I've talked too expects their software to be bug free.

THIS is what we mean when we say stable:
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read stable.


D does have a test suite, and it is a (almost always achieved) goal to  
keep it always passing, even on the dev branch. In fact, most of my work  
is running the test suite and making sure each change doesn't regress.  
(Regressions that do slip through were not in the test suite.)


Frankly, I don't know how to do what you're asking for. D users, every  
single day, clamor for:


1. more bug fixes


Branch A. Rebase into Branch B as needed.


2. more new features


Branch B.


3. why aren't deprecated features removed more quickly?


Branch A, marked for deprecation.
Branch B, actually removed. Becomes active when merged into Branch A.
(Assuming Branch B is merged roughly every other month as per current  
processes.)



4. why don't we add this breaking feature?


Add it. Branch B.


5. why did you add that breaking feature which broke my code?


Why are you using Branch B you knucklehead?


Often, these are the same people! Sometimes, even in the same post!


This concept is precisely designed to significantly mitigate all five  
problems.


Not everyone will test against Repo B, but this allows you to put the  
responsibility for not testing against it on them. They know how it works  
here, it's not your problem if you broke something that they had the  
chance to test for but didn't.


And, to reiterate, we did release D1. Since its release, it has only  
received bug fixes. No breaking changes, no regressions. This,  
inevitably, has made many D1 users unhappy - they wanted new features  
folded in.


So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all  
these mutually contradictory requests.


I do apologize for that. It is not my intention to cause undue stress. I  
am pushing the for the change because I think it will mitigate much of  
your current stress in dealing with us. And I do recognize that we users  
can be pretty demanding as I sit on the other side of this equation at  
work. But because I sit on the other side, I get frustrated when I see  
developers actively resisting the proven concepts that will drastically  
reduce the very problem they are complaining about.


I should note that we use this exact model for every project we have where  
I work and that it is been highly successful at keeping those five points  
of tension moderated. And our users can actually get work done without  
waiting for weeks and months because thing X is just plain broken, which  
in turn makes us look good. (Improving Loyalty)


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning


On 16/07/2012 01:06, Walter Bright wrote:

Frankly, I don't know how to do what you're asking for. D users, every
single day, clamor for:

1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!



I understand that this may seems messed up. It isn't as much as it 
seems. It simply show the need for a more elaborate versionning and 
releasing system for D.


Theses needs do all exists. But not all at the same time or all in the 
same situation.


When dealing with code, as in all engineering fields, you always make 
tradeoffs. And changing things in a codebase have a cost. Presumably, 
every feature which are included into D has also a benefit.


The larger your codebase, the more interesting it is to slow down 
inclusion of new feature in your work. The smaller, the quicker you want 
to do it because the cost of doing so isn't the same, and you can 
benefit from the news feature at a very little cost.


Different situations, different needs. The same person can have both 
need at the same time, because it have experienced both situations with 
different codebases.



And, to reiterate, we did release D1. Since its release, it has only
received bug fixes. No breaking changes, no regressions. This,
inevitably, has made many D1 users unhappy - they wanted new features
folded in.

So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all
these mutually contradictory requests.


As of D1, the problem is different.

I'll use again the example of PHP, because it has proven to manage the 
issue quite well, and because I discussed that quite a lot with Ramsus 
recently, so I know the topic quite well.


PHP release PHP 5.2 . Then it released PHP6 . PHP introduced breaking 
changes, just like D2 does. We can compare D1 as PHP5.2 and D2 as PHP6 .


It happened that some new feature of PHP6 weren't breaking features (GC, 
closures, namespaces) and some other were (introducing unicode into 
source code).


And here is what is done then, and here what we should learn from PHP. 
After PHP6, PHP relased PHP5.3 . PHP5.3 was basically PHP5.2 with all 
new feature of PHP6, except the one that was breaking.


PHP5.2 continued to live for very conservative users, 5.3 for user that 
want to use new features, and 6 for users that feel like beta testers.


(note 6 was then canceled, but for reasons completely unrelated to what 
we are talking here. I may talk about that, but this is really off topic 
here, so let's not epilogue on that).

Re: D versionning


On 16/07/2012 01:07, Walter Bright wrote:

On 7/15/2012 3:43 PM, Jonathan M Davis wrote:

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:

On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the
breakage relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming
library
functions.


Yeah, but those are always done through a deprecation path, so there's no
immediate breakage. And we've done most of that already, so that
should be
happening less and less.


It needs to stop completely.



No. It hasn't been made for no reasons.

But yes, some code is broken in the process. This is exactly why we need 
a more sophisticated versionning process (note the recurring pattern in 
my posts :D ).


The fact that some people have legacy code shouldn't stop D progress. 
But with the current system, D must either break code or make no progress.

Re: D versionning

On Sunday, July 15, 2012 19:43:44 Patrick Stewart wrote:
 Completely not relevant. Number of developers have nothing to do with
 project organization. There is a lot of software there equal or more
 complex that are product of just a few or even single programmer.

Actually, it's _very_ relevant. If release model A takes up more time and 
resources than release model B, then release model A will slow down 
development. For projects with more developers, it may be possible to mitigate 
those costs such that the benefits outweigh them, but for projects with fewer 
developers, a slower release model may be completely unacceptable. It all 
depends on what the various pros and cons are and how they will affect the 
project.

It may very well be that the proposed release model is well worth going to, 
but it could also be that its benefits aren't worth its costs, and the number 
of developers involved has a definite effect on that calculation.

- Jonathan M Davis

Re: D versionning


On 16/07/2012 01:42, Jonathan M Davis wrote:

On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:

Sigh. Half say we release too often, the other half not often enough.


Which is actually one argument for going to a model where you have frequent
minor releases which only contain bug fixes and less frequent major releases
with the larger changes. You can never make everyone happy, but by doing so,
you get the bug fixes faster for the folks complaining about the lack of
frequent releases, and you get increased stability as far as the new stuff
goes, because it doesn't come with every release.

I'm only against the proposed versioning scheme because I think that we need
to stabilize things better (e.g. actually have all of the features that TDPL
lists fully implemented) before we move to it. But I fully support moving to
this sort of scheme in the long run. It manages change much better, and I
think that many, many existing projects have shown that it promotes stable
code bases while still allowing for them to evolve as necessary.

- Jonathan M Davis


The proposed scheme is only a proposed scheme. Other solutions exist 
that solve the problem, and if they better fit, why not ?

Re: D versionning

On Monday, July 16, 2012 02:07:13 deadalnix wrote:
 On 16/07/2012 01:42, Jonathan M Davis wrote:
  On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
  Sigh. Half say we release too often, the other half not often enough.
  
  Which is actually one argument for going to a model where you have
  frequent
  minor releases which only contain bug fixes and less frequent major
  releases with the larger changes. You can never make everyone happy, but
  by doing so, you get the bug fixes faster for the folks complaining about
  the lack of frequent releases, and you get increased stability as far as
  the new stuff goes, because it doesn't come with every release.
  
  I'm only against the proposed versioning scheme because I think that we
  need to stabilize things better (e.g. actually have all of the features
  that TDPL lists fully implemented) before we move to it. But I fully
  support moving to this sort of scheme in the long run. It manages change
  much better, and I think that many, many existing projects have shown
  that it promotes stable code bases while still allowing for them to
  evolve as necessary.
  
  - Jonathan M Davis
 
 The proposed scheme is only a proposed scheme. Other solutions exist
 that solve the problem, and if they better fit, why not ?

If someone has a better proposal, they should make it (though probably in a 
separate thread - this one's long enough as it is). I think that the basics of 
this proposal are good, and a lot of projects work that way. I just think that 
D needs to be more stable before we worry about having major and minor 
releases or stable and unstable branches.

- Jonathan M Davis

Re: D versionning

On Sun, 15 Jul 2012 17:20:33 -0700, Jonathan M Davis jmdavisp...@gmx.com  
wrote:



On Monday, July 16, 2012 02:07:13 deadalnix wrote:

On 16/07/2012 01:42, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
 Sigh. Half say we release too often, the other half not often enough.

 Which is actually one argument for going to a model where you have
 frequent
 minor releases which only contain bug fixes and less frequent major
 releases with the larger changes. You can never make everyone happy,  
but
 by doing so, you get the bug fixes faster for the folks complaining  
about
 the lack of frequent releases, and you get increased stability as far  
as

 the new stuff goes, because it doesn't come with every release.

 I'm only against the proposed versioning scheme because I think that  
we
 need to stabilize things better (e.g. actually have all of the  
features

 that TDPL lists fully implemented) before we move to it. But I fully
 support moving to this sort of scheme in the long run. It manages  
change

 much better, and I think that many, many existing projects have shown
 that it promotes stable code bases while still allowing for them to
 evolve as necessary.

 - Jonathan M Davis

The proposed scheme is only a proposed scheme. Other solutions exist
that solve the problem, and if they better fit, why not ?


If someone has a better proposal, they should make it (though probably  
in a
separate thread - this one's long enough as it is). I think that the  
basics of
this proposal are good, and a lot of projects work that way. I just  
think that

D needs to be more stable before we worry about having major and minor
releases or stable and unstable branches.

- Jonathan M Davis


I guess I just see it as differing definitions of stable. For example,  
dsimcha was here not twenty hours ago praising D for how stable it's  
become.


I think this is a pretty good summation of stable in the community project  
context:

http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

Note: We meet all criteria for stable.

--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:
 I guess I just see it as differing definitions of stable. For example,
 dsimcha was here not twenty hours ago praising D for how stable it's
 become.
 
 I think this is a pretty good summation of stable in the community project
 context:
 http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
 
 Note: We meet all criteria for stable.

What I want to see is dmd having fully implemented all of the features in TDPL 
(e.g. multiple alias thises) and sorted out all of the major design or 
implementation issues (e.g. the issues with const and Object). After that, D2 
has been fully implemented, and we can look at adding new features if we want 
to and restricting those as well as any breaking changes that we need to make 
to a different branch which only gets merged into the main branch in certain 
releases.

Arguably, we've been adding too many new features (e.g. new lambda syntax and 
SIMD support), given that we're supposed to be making everything that we 
already  have work properly, but those features haven't been breaking changes, 
and presumably forcing Walter to just fix bugs wouldn't be all that pleasant 
for him. But until we've fully implemented what we have, I think that it's 
just going to slow us down to little benefit to change the release model. Once 
we have, _then_ I'd love to see a release model which promotes major vs minor 
releases and the like, because then we can evolve the language and library as 
appropriate while still maintaining stable releases which programmers can rely 
on for long periods of time without worrying about breaking changes and 
whatnot.

- Jonathan M Davis

Re: D versionning

2012-07-15 Thread Andrei Alexandrescu


On 7/15/12 7:06 PM, Walter Bright wrote:

Frankly, I don't know how to do what you're asking for. D users, every
single day, clamor for:

1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!

And, to reiterate, we did release D1. Since its release, it has only
received bug fixes. No breaking changes, no regressions. This,
inevitably, has made many D1 users unhappy - they wanted new features
folded in.

So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all
these mutually contradictory requests.


I think you're conflating two different trends. One is the annoying one 
you mentioned, and the other is a very reasonable request - that D has 
one branch containing only bug fixes, and another branch with new 
features and other potentially disruptive things.


The key is that the branches are merged once a more risky branch is 
stable enough, and the essential ingredient is that git makes branch 
merging easy.


This is not something you could have done essentially at any pre-github 
time in D's history, and is not to be confused with D1 vs D2 or with the 
known contradictory requests.



Andrei

Re: D versionning

On Sun, 15 Jul 2012 17:36:28 -0700, Jonathan M Davis jmdavisp...@gmx.com  
wrote:



On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:

I guess I just see it as differing definitions of stable. For example,
dsimcha was here not twenty hours ago praising D for how stable it's
become.

I think this is a pretty good summation of stable in the community  
project

context:
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

Note: We meet all criteria for stable.


What I want to see is dmd having fully implemented all of the features  
in TDPL

(e.g. multiple alias thises) and sorted out all of the major design or
implementation issues (e.g. the issues with const and Object). After  
that, D2
has been fully implemented, and we can look at adding new features if we  
want
to and restricting those as well as any breaking changes that we need to  
make
to a different branch which only gets merged into the main branch in  
certain

releases.

Arguably, we've been adding too many new features (e.g. new lambda  
syntax and

SIMD support), given that we're supposed to be making everything that we
already  have work properly, but those features haven't been breaking  
changes,
and presumably forcing Walter to just fix bugs wouldn't be all that  
pleasant
for him. But until we've fully implemented what we have, I think that  
it's
just going to slow us down to little benefit to change the release  
model. Once
we have, _then_ I'd love to see a release model which promotes major vs  
minor
releases and the like, because then we can evolve the language and  
library as
appropriate while still maintaining stable releases which programmers  
can rely

on for long periods of time without worrying about breaking changes and
whatnot.

- Jonathan M Davis


I think the problem is that in the real world, that state is somewhat  
unlikely. For example, Walter is currently working on COFF support, this  
is arguably a new feature (we already can make programs work on Windows).  
Programmers aren't machines and fixing bugs all day is boring, we want to  
do the fun stuff, in this case, new features. It just so happens that it's  
the fun stuff that makes fixing bugs bearable. I don't think it's fair of  
us to demand that Walter only fix bugs, besides, COFF support is a HIGHLY  
requested new feature, he is just supposed to ignore them?


It is never easy deciding which new features to add versus which bugs to  
fix, but that's the beauty of this model, you don't have to. You just do  
both.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning