July 12, 2012
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.
July 13, 2012
On 2012-07-13 00:24, Adam Wilson wrote:

> For example:
> 2.0.60 is the current HEAD. Bug fixes Only.
> 2.1.60 is the new feature branch. It is a GitHub fork of the current
> DMD-HEAD owned by the same org as current DMD-HEAD. This way Walter can
> work against both simultaneously.
>
> We could have rolled the Object const change in 2.1.60, found out we
> didn't like them but instead of being FORCED to revert it to keep 2.060
> stable, we could have continued developing and improving the model or
> working on the problem from a completely different angle, WITHOUT
> affecting the release of 2.0.60.
>
> We could keep all the COFF work in the DMD 2.1 branch without affecting
> DMD 2.0 branch and having nearly as many breakages as we currently do in
> HEAD. Most recently, the ElfObj breakage. Roll that work into 2.1.60 and
> if it breaks well, you KNEW you were on the development branch, what's
> your problem?
>
> The stable/development branch model exists for a reason, it works, well.
> We don't have to keep rediscovering the models that worked successfully
> for other teams the hard way. If we proactively seek best practices, we
> can proactively avoid a huge amount of pain.

Yeah, I still don't understand why we don't do this. Is Walter against this? Anyone else?

-- 
/Jacob Carlborg


July 13, 2012
On Thu, 12 Jul 2012 23:43:40 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2012-07-13 00:24, Adam Wilson wrote:
>
>> For example:
>> 2.0.60 is the current HEAD. Bug fixes Only.
>> 2.1.60 is the new feature branch. It is a GitHub fork of the current
>> DMD-HEAD owned by the same org as current DMD-HEAD. This way Walter can
>> work against both simultaneously.
>>
>> We could have rolled the Object const change in 2.1.60, found out we
>> didn't like them but instead of being FORCED to revert it to keep 2.060
>> stable, we could have continued developing and improving the model or
>> working on the problem from a completely different angle, WITHOUT
>> affecting the release of 2.0.60.
>>
>> We could keep all the COFF work in the DMD 2.1 branch without affecting
>> DMD 2.0 branch and having nearly as many breakages as we currently do in
>> HEAD. Most recently, the ElfObj breakage. Roll that work into 2.1.60 and
>> if it breaks well, you KNEW you were on the development branch, what's
>> your problem?
>>
>> The stable/development branch model exists for a reason, it works, well.
>> We don't have to keep rediscovering the models that worked successfully
>> for other teams the hard way. If we proactively seek best practices, we
>> can proactively avoid a huge amount of pain.
>
> Yeah, I still don't understand why we don't do this. Is Walter against this? Anyone else?

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

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 13, 2012
On 2012-07-13 08:52, Adam Wilson wrote:

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

If he's not against it, I see know reason why this haven't been done already.

-- 
/Jacob Carlborg


July 13, 2012
On Fri, 13 Jul 2012 00:11:12 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2012-07-13 08:52, Adam Wilson wrote:
>
>> I hope Walter isn't against this, because I'm not seeing much community
>> disagreement with this...
>
> If he's not against it, I see know reason why this haven't been done already.

Concurred. The next step is probably to send emails to Walter/Andrei detailing our case.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 13, 2012
On Friday, 13 July 2012 at 06:52:25 UTC, Adam Wilson wrote:
> I hope Walter isn't against this, because I'm not seeing much community disagreement with this...

I would not be against having development and stable versions, but the price is not trivial: every pull request must be done in at least two branches, probably diverging significantly. And most benefits are already available: we have the git version and the last stable version (of course, the latter would be without the latest bug-fixes). That would mean slower progress in applying existing pull requests. (There are 100+ of those, aren't there?)

Also, nobody is preventing any person that considers this to be very important from creating a fork of stable branch and applying bug-fixes there. If this happens to be a very useful option, then it could be accepted as a policy.

So my point of view is that it might be too early to have such policy yet.
July 13, 2012
On Friday, July 13, 2012 09:30:47 Roman D. Boiko wrote:
> So my point of view is that it might be too early to have such policy yet.

Which was my point. I think that we'll need to switch to a model like that eventually, but things are still in too much flux for it to make sense yet. Switching now would just slow everything down.

- Jonathan M Davis
July 13, 2012
"deadalnix"  wrote in message news:jtn1ol$juu$1@digitalmars.com...

On 12/07/2012 19:31, Iain Buclaw wrote:
> On 12 July 2012 17:49, deadalnix<deadalnix@gmail.com>  wrote:
>> One thing PHP has been good at is evolving, and introducing change in the
>> language (some can argument that the language is so fucked up that this is
>> unavoidable, so I do it now and we can discuss interesting topic).
>>
>> I discussed that system with Rasmus Ledorf at afup 2012 and it something
>> that D should definitively look into.
>>
>> The const vs OOP discussion have shown once again that D will have to
>> introduce breaking changes in the language. This isn't easy matter because
>> if we break people code, D isn't attractive. But as long as code isn't
>> broken, D people can't worked on what's next and it slows down D progress.
>>
>> 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.
>>
>> The last one is reserved for bug fixes. Several version are maintained at
>> the same time (even if a large amount of code base is common, so bug fixes
>> can be used for many version at the time).
>>
>> We should leverage the benefit of having switched to git to go in that way.
>> We can start right now D2.1.xx with the opX dropped from object and see how
>> it goes without requiring everybody to switch now.
>>
>> Such a system would also permit to drop all D1 stuff that are in current DMD
>> because D1 vs D2 can be chosen at compile time on the same sources.
>>
>> git provide all we need to implement such a process, it is easy to do it
>> soon (after 2.060 for instance) because it doesn't imply drastic changes for
>> users.
>
> Might as well just say "Lets start D3 now - Let's drop all features
> that have been deprecated since 0.103 - everyone make a hype and
> party!"
>
>

> No, user will need backward compatible support for any real life work.

This is why besides some small D toy projects, I keep using C++(11) for any native coding at work
when the oportunity surfaces.

While I keep complaining on Go forums that I don't like that the language lacks enums and
generics, the way Google oposes language featuritis and is keen on Go 1 stability, makes it easier
to sell to management.

--
Paulo 

July 13, 2012
On 13/07/2012 09:37, Jonathan M Davis wrote:
> On Friday, July 13, 2012 09:30:47 Roman D. Boiko wrote:
>> So my point of view is that it might be too early to have such
>> policy yet.
>
> Which was my point. I think that we'll need to switch to a model like that
> eventually, but things are still in too much flux for it to make sense yet.
> Switching now would just slow everything down.
>
> - Jonathan M Davis

Just think about how long this -property thing is around, since when the delete or scope has been deprecated, and that all of this doesn't even give a warning or something when the compiler stumble on them.
July 13, 2012
On 2012-07-13 09:37, Jonathan M Davis wrote:

> Which was my point. I think that we'll need to switch to a model like that
> eventually, but things are still in too much flux for it to make sense yet.
> Switching now would just slow everything down.

We could have more of an experimental branch which would be used for testing bigger changes or changes that will impact a lot of code.

-- 
/Jacob Carlborg