View mode: basic / threaded / horizontal-split · Log in · Help
July 23, 2012
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 22 de July a las 16:05 me escribiste:
> I can't really say, but it sounds like what you are asking for is
> D2/D3, thats not really the scope of the dlang-stable project, we

Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
said before in this thread talking about PHP, minor version changes in
the languages should only introduce backward compatible new features. D3
should be allowed to break backward compatibility while D 2.1 should
not. The same is done in Python. In Python is even allowed to break
backward compatibility in very small and are cases, like introducing
a keyword. In those cases the changes are introduced in steps, let's say
in Python 2.5 with is not a keyword and they want to convert it to
a keyword. Then in Python 2.6 you have an option to enable that
behaviour (disabled by default) and in Python 2.7 the new feature will
be enabled by default. Python 2.5.1 can only introduce bugfixes.

This is something I think D needs since ages ago[1], and I thought it was
finally here, but from what you say it doesn't like that way :S

[1] http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
There is no pain you are receding
A distant ship, smoke on the horizon.
You are only coming through in waves.
Your lips move but I can't hear what you're saying.
July 23, 2012
Re: Coming Soon: Stable D Releases!
On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella <luca@llucax.com.ar>  
wrote:

> Adam Wilson, el 22 de July a las 16:05 me escribiste:
>> I can't really say, but it sounds like what you are asking for is
>> D2/D3, thats not really the scope of the dlang-stable project, we
>
> Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
> said before in this thread talking about PHP, minor version changes in
> the languages should only introduce backward compatible new features. D3
> should be allowed to break backward compatibility while D 2.1 should
> not. The same is done in Python. In Python is even allowed to break
> backward compatibility in very small and are cases, like introducing
> a keyword. In those cases the changes are introduced in steps, let's say
> in Python 2.5 with is not a keyword and they want to convert it to
> a keyword. Then in Python 2.6 you have an option to enable that
> behaviour (disabled by default) and in Python 2.7 the new feature will
> be enabled by default. Python 2.5.1 can only introduce bugfixes.

Minor release ARE what we are hoping for, but you'll have to convince  
Walter and company to move to that scheme, it's out of my control. For the  
moment, we will be using a scheme that looks like 2.60.1. Which may be  
what you are talking about. When it's time to roll in the new features and  
breaking fixes the stable release will be bumped to 2.61.1. Is this what  
you are asking for?

> This is something I think D needs since ages ago[1], and I thought it was
> finally here, but from what you say it doesn't like that way :S
>
> [1]  
> http://www.llucax.com.ar/blog/blog/post/6cac01e1#source-control-and-versioning
>
> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> There is no pain you are receding
> A distant ship, smoke on the horizon.
> You are only coming through in waves.
> Your lips move but I can't hear what you're saying.


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 24, 2012
Re: Coming Soon: Stable D Releases!
On 16/07/12 09:51, Adam Wilson wrote:
> As a result of the D Versioning thread, we have decided to create a new
> organization on Github called dlang-stable. This organization will be
> responsible for maintaining stable releases of DMD, DRuntime, and Phobos.
>
> So what is a stable release?
> A stable release is a complete build of DMD, DRuntime, and Phobos that
> ONLY includes the latest bug-fixes and non-breaking enhancements to
> existing features. It will not include, new features, breaking
> enhancements, and any other code that the core development team may be
> working on.

I'm not actually sure what this means. I fear that it may be motivated 
by an inaccurate assessment of the current situation.

The existing instability comes almost entirely from Phobos, not from the 
compiler. Historically there have been very few instances where you 
might want to choose an older compiler in preference to the latest release.

As I've said before, the one time when a language change caused 
*massive* instability was in the attempt to move AAs from language to 
library -- even though that wasn't even supposed to affect existing code 
in any way. The other thing that typically causes regressions is fixes 
to forward-reference bugs.

Historically, addition of new language features has NOT caused 
instability. What has been true is that features have been added to the 
compiler before they were really usable, but they have not broken 
existing code. Fairly obviously the 64 bit compiler was quite buggy when 
initially released. But even that massive change wasn't much more buggy 
than the library AAs! So I am not sure that you can correctly guess 
where instability will come from.

In summary -- I would not expect your stable DMD to be very different 
from the normal DMD. Phobos is where the instability issue is.
July 24, 2012
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu 
wrote:
> I agree this would be more direct. But I fail to see how Walter 
> cherry-picking stuff is "basically no additional work", whereas 
> Adam doing essentially the same is an unenviable "amount of 
> labor".

The difference is Walter (and other developers) knows his changes 
intimately.

The whole point of dlang-stable is to deliver bug-fixes more 
quickly. To make this work developers should fix bugs in separate 
branch, and do separate commit (IIUC, which I'm not quite sure). 
So it's virtually zero effort on their side.

On the other hand, Adam must look at this code really closely. 
Now add to the picture other developers whom changes Adam will 
need to examine too. All of his D-love energy will be consumed by 
maybe 5 developers. And I don't understand what benefits are 
(given zero effort for developers).

This doesn't scale. At some point number of the compiler 
developers will be 100 times then it is now. And that will 
require 100 times more Adams to handle the stream.


> Besides, if Walter is at the same time doing things and 
> deciding their category may work worse than a small team making 
> the assessment by consensus.

That (few people reviewing same patches) would scale even worse.


B.t.w. how does Linux kernel people handle this ?
July 24, 2012
Re: Coming Soon: Stable D Releases!
On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac@nospam.com> wrote:

> On 16/07/12 09:51, Adam Wilson wrote:
>> As a result of the D Versioning thread, we have decided to create a new
>> organization on Github called dlang-stable. This organization will be
>> responsible for maintaining stable releases of DMD, DRuntime, and  
>> Phobos.
>>
>> So what is a stable release?
>> A stable release is a complete build of DMD, DRuntime, and Phobos that
>> ONLY includes the latest bug-fixes and non-breaking enhancements to
>> existing features. It will not include, new features, breaking
>> enhancements, and any other code that the core development team may be
>> working on.
>
> I'm not actually sure what this means. I fear that it may be motivated  
> by an inaccurate assessment of the current situation.
>
> The existing instability comes almost entirely from Phobos, not from the  
> compiler. Historically there have been very few instances where you  
> might want to choose an older compiler in preference to the latest  
> release.
>
> As I've said before, the one time when a language change caused  
> *massive* instability was in the attempt to move AAs from language to  
> library -- even though that wasn't even supposed to affect existing code  
> in any way. The other thing that typically causes regressions is fixes  
> to forward-reference bugs.
>
> Historically, addition of new language features has NOT caused  
> instability. What has been true is that features have been added to the  
> compiler before they were really usable, but they have not broken  
> existing code. Fairly obviously the 64 bit compiler was quite buggy when  
> initially released. But even that massive change wasn't much more buggy  
> than the library AAs! So I am not sure that you can correctly guess  
> where instability will come from.
>
> In summary -- I would not expect your stable DMD to be very different  
> from the normal DMD. Phobos is where the instability issue is.

There are three issues we are trying to address:

The first and largest issue is the long and variable periods between DMD  
releases. By the end of the 2.060 Beta period there will have been at  
least 3.5 months since 2.059. And while for the people who can use Git  
HEAD this may not be a problem, there are MANY who, for whatever reason,  
must use the released versions. For them the 314 resolved issues and  
dozens of regressions fixed are a tantalizingly out of reach.

The second issue is the root of the first. Much of the delay was caused by  
Walter starting to work on COFF. Which brings up the second point of  
contention in the community, a significant number of bugs are typically  
introduced when this new work is introduced precisely because it's not  
ready, and the effort required to make it stable would significantly delay  
the release, which loops back to the first problem of release cadence.  
Yes, D is more stable than ever, but we keep breaking it to push bugfix  
builds because the community starts to get restless without bugfixes.  
Which is the whole reason this stable project got started.

The third is the result of the first two. The slow release cadence  
combined with the requirement to push new features along side bug-fixes is  
seriously holding back the growth of the D community. There is a feeling  
out here that D is lurching unsteadily forward when it should be smoothly  
accelerating and most of this feeling is rooted in the prior two causes.  
This has a very corrosive effect on the community and particularly their  
willingness to contribute.

The goal of dlang-stable is to provide the primary development team (you!)  
with the ability to release whenever you feel a new feature or enhancement  
is stable enough to be released WITHOUT having to worry about the ever  
growing number of bugfixes that are backlogged in with the new features.  
We are trying to reduce the bugfix pressure so that you can focus on  
delivering high-quality code when it's ready.

The community WANTS these new features, but we CAN'T wait 3.5 months (or  
more!) for the bugfixes that are baked in with them. We have to provide  
BOTH.

That is dlang-stable.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 24, 2012
Re: Coming Soon: Stable D Releases!
Adam Wilson, el 23 de July a las 11:07 me escribiste:
> On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella
> <luca@llucax.com.ar> wrote:
>
> >Adam Wilson, el 22 de July a las 16:05 me escribiste:
> >>I can't really say, but it sounds like what you are asking for is
> >>D2/D3, thats not really the scope of the dlang-stable project, we
> >
> >Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
> >said before in this thread talking about PHP, minor version changes in
> >the languages should only introduce backward compatible new features. D3
> >should be allowed to break backward compatibility while D 2.1 should
> >not. The same is done in Python. In Python is even allowed to break
> >backward compatibility in very small and are cases, like introducing
> >a keyword. In those cases the changes are introduced in steps, let's say
> >in Python 2.5 with is not a keyword and they want to convert it to
> >a keyword. Then in Python 2.6 you have an option to enable that
> >behaviour (disabled by default) and in Python 2.7 the new feature will
> >be enabled by default. Python 2.5.1 can only introduce bugfixes.
>
> Minor release ARE what we are hoping for, but you'll have to
> convince Walter and company to move to that scheme, it's out of my

Are you talking about the development model or just the version naming
scheme?

> control. For the moment, we will be using a scheme that looks like
> 2.60.1. Which may be what you are talking about. When it's time to
> roll in the new features and breaking fixes the stable release will
> be bumped to 2.61.1. Is this what you are asking for?

I guess. But if after 2.60.1, when you want to make a new "minor"
release with new features, you fork it from, say, 2.064, I would name
that new version, 2.64.1 instead of 2.61.1. Or with that comment you are
implying that there will be "minor" release for each and every official
release? Also, are you planning to drop the leading 0 in the version
number or was just a typo?

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
	-- Sidharta Kiwi
July 24, 2012
Re: Coming Soon: Stable D Releases!
On Tue, 24 Jul 2012 11:41:52 -0700, Leandro Lucarella <luca@llucax.com.ar>  
wrote:

> Adam Wilson, el 23 de July a las 11:07 me escribiste:
>> On Mon, 23 Jul 2012 01:52:57 -0700, Leandro Lucarella
>> <luca@llucax.com.ar> wrote:
>>
>> >Adam Wilson, el 22 de July a las 16:05 me escribiste:
>> >>I can't really say, but it sounds like what you are asking for is
>> >>D2/D3, thats not really the scope of the dlang-stable project, we
>> >
>> >Nope! What I'm talking about is D 2.1, 2.2, etc. Not D3. As somebody
>> >said before in this thread talking about PHP, minor version changes in
>> >the languages should only introduce backward compatible new features.  
>> D3
>> >should be allowed to break backward compatibility while D 2.1 should
>> >not. The same is done in Python. In Python is even allowed to break
>> >backward compatibility in very small and are cases, like introducing
>> >a keyword. In those cases the changes are introduced in steps, let's  
>> say
>> >in Python 2.5 with is not a keyword and they want to convert it to
>> >a keyword. Then in Python 2.6 you have an option to enable that
>> >behaviour (disabled by default) and in Python 2.7 the new feature will
>> >be enabled by default. Python 2.5.1 can only introduce bugfixes.
>>
>> Minor release ARE what we are hoping for, but you'll have to
>> convince Walter and company to move to that scheme, it's out of my
>
> Are you talking about the development model or just the version naming
> scheme?
>
>> control. For the moment, we will be using a scheme that looks like
>> 2.60.1. Which may be what you are talking about. When it's time to
>> roll in the new features and breaking fixes the stable release will
>> be bumped to 2.61.1. Is this what you are asking for?
>
> I guess. But if after 2.60.1, when you want to make a new "minor"
> release with new features, you fork it from, say, 2.064, I would name
> that new version, 2.64.1 instead of 2.61.1. Or with that comment you are
> implying that there will be "minor" release for each and every official
> release? Also, are you planning to drop the leading 0 in the version
> number or was just a typo?

Yes, the minor will match the minor it's forked from, that is important to  
semantically understanding which release the bugfixes apply to.

There will many releases per minor. So 2.060.1, 2.060.2, etc. I am hoping  
for packaged releases every week.

I would like to drop the leading 0, but I think it would be confusing to  
people to not have them exactly match D's current scheme.

> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
> 	-- Sidharta Kiwi


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 25, 2012
Re: Coming Soon: Stable D Releases!
On 24/07/12 19:27, Adam Wilson wrote:
> On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac@nospam.com> wrote:
>
>> On 16/07/12 09:51, Adam Wilson wrote:
>>> As a result of the D Versioning thread, we have decided to create a new
>>> organization on Github called dlang-stable. This organization will be
>>> responsible for maintaining stable releases of DMD, DRuntime, and
>>> Phobos.
>>>
>>> So what is a stable release?
>>> A stable release is a complete build of DMD, DRuntime, and Phobos that
>>> ONLY includes the latest bug-fixes and non-breaking enhancements to
>>> existing features. It will not include, new features, breaking
>>> enhancements, and any other code that the core development team may be
>>> working on.
>>
>> I'm not actually sure what this means. I fear that it may be motivated
>> by an inaccurate assessment of the current situation.
>>
>> The existing instability comes almost entirely from Phobos, not from
>> the compiler. Historically there have been very few instances where
>> you might want to choose an older compiler in preference to the latest
>> release.
>>
>> As I've said before, the one time when a language change caused
>> *massive* instability was in the attempt to move AAs from language to
>> library -- even though that wasn't even supposed to affect existing
>> code in any way. The other thing that typically causes regressions is
>> fixes to forward-reference bugs.
>>
>> Historically, addition of new language features has NOT caused
>> instability. What has been true is that features have been added to
>> the compiler before they were really usable, but they have not broken
>> existing code. Fairly obviously the 64 bit compiler was quite buggy
>> when initially released. But even that massive change wasn't much more
>> buggy than the library AAs! So I am not sure that you can correctly
>> guess where instability will come from.
>>
>> In summary -- I would not expect your stable DMD to be very different
>> from the normal DMD. Phobos is where the instability issue is.
>
> There are three issues we are trying to address:
>
> The first and largest issue is the long and variable periods between DMD
> releases. By the end of the 2.060 Beta period there will have been at
> least 3.5 months since 2.059. And while for the people who can use Git
> HEAD this may not be a problem, there are MANY who, for whatever reason,
> must use the released versions. For them the 314 resolved issues and
> dozens of regressions fixed are a tantalizingly out of reach.

I agree, but the fact that has happened, is just plain silly. There is 
no sensible reason why this happened. We were in fact ready for a 
release nearly two months ago. Somehow it did not happen. That 
ridiculous situation is the thing that needs to be addressed, IMHO.

In fact, I see no reason why we couldn't do a release every month.

> The second issue is the root of the first. Much of the delay was caused
> by Walter starting to work on COFF. Which brings up the second point of
> contention in the community, a significant number of bugs are typically
> introduced when this new work is introduced precisely because it's not
> ready,

I do not believe that at all. Where is the evidence for it?

> The third is the result of the first two. The slow release cadence
> combined with the requirement to push new features along side bug-fixes
> is seriously holding back the growth of the D community. There is a
> feeling out here that D is lurching unsteadily forward when it should be
> smoothly accelerating and most of this feeling is rooted in the prior
> two causes. This has a very corrosive effect on the community and
> particularly their willingness to contribute.
>
> The goal of dlang-stable is to provide the primary development team
> (you!) with the ability to release whenever you feel a new feature or
> enhancement is stable enough to be released WITHOUT having to worry
> about the ever growing number of bugfixes that are backlogged in with
> the new features. We are trying to reduce the bugfix pressure so that
> you can focus on delivering high-quality code when it's ready.
>
> The community WANTS these new features, but we CAN'T wait 3.5 months (or
> more!) for the bugfixes that are baked in with them. We have to provide
> BOTH.

We don't need this complexity. The solution is *trivial*. We just need 
to decide in advance that we will target a release every X weeks, and 
that it should be delayed only for reasons of stability.

An agreement is ALL that is required. But despite repeated requests, I 
have never been able to get any traction on the idea.
Instead, people propose all kinds of crazy technical solutions, the most 
recent ones being changes to bugzilla, trello, and now dlang-stable.

If we say, "There will be a new compiler release every 8 weeks", the 
problem is solved. Seriously. That one-off agreement is ALL that is 
required.

But the D community finds it easier to implement a new 64-bit Windows 
compiler, than to make a agreement on a short-term release schedule. 
We're a strange bunch, I tell you.
July 25, 2012
Re: Coming Soon: Stable D Releases!
On 2012-07-25 09:43, Don Clugston wrote:

> We don't need this complexity. The solution is *trivial*. We just need
> to decide in advance that we will target a release every X weeks, and
> that it should be delayed only for reasons of stability.

Yeah, but what happens when Walter or someone else decides to start a 
big project, i.e. implementing COFF support, a week before release? We 
end up with a bunch of half finished things.

A solution to this would be to create a new branch or not push the 
changes upstream. Although I don't understand why Walter doesn't already 
do this.

> An agreement is ALL that is required. But despite repeated requests, I
> have never been able to get any traction on the idea.
> Instead, people propose all kinds of crazy technical solutions, the most
> recent ones being changes to bugzilla, trello, and now dlang-stable.
>
> If we say, "There will be a new compiler release every 8 weeks", the
> problem is solved. Seriously. That one-off agreement is ALL that is
> required.

Apparently it seems very difficult to agree upon, since it hasn't 
happened. The releases just pop up at random.

-- 
/Jacob Carlborg
July 25, 2012
Re: Coming Soon: Stable D Releases!
On 25/07/12 14:32, Jacob Carlborg wrote:
> On 2012-07-25 09:43, Don Clugston wrote:
>
>> We don't need this complexity. The solution is *trivial*. We just need
>> to decide in advance that we will target a release every X weeks, and
>> that it should be delayed only for reasons of stability.
>
> Yeah, but what happens when Walter or someone else decides to start a
> big project, i.e. implementing COFF support, a week before release? We
> end up with a bunch of half finished things.

If we had an agreed release cycle, it would not happen. The release 
cycle would be a higher authority than any single person, even Walter.

> A solution to this would be to create a new branch or not push the
> changes upstream. Although I don't understand why Walter doesn't already
> do this.
>
>> An agreement is ALL that is required. But despite repeated requests, I
>> have never been able to get any traction on the idea.
>> Instead, people propose all kinds of crazy technical solutions, the most
>> recent ones being changes to bugzilla, trello, and now dlang-stable.
>>
>> If we say, "There will be a new compiler release every 8 weeks", the
>> problem is solved. Seriously. That one-off agreement is ALL that is
>> required.
>
> Apparently it seems very difficult to agree upon, since it hasn't
> happened. The releases just pop up at random.

I have tried many times, without success. I've never succeeded in 
getting more than two or three people interested.
2 3 4 5 6 7
Top | Discussion index | About this forum | D home