Julio César Carrascal Urquijo wrote:
> On question, though. How does DMD decide to split a module in servera .obj files? By class or once a threshold is reached?

It's done for things that would be generated in multiple files, like template instantiations and typeinfo data.

Bill Baxter wrote:
> Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]

I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.

Walter Bright wrote:
> Bill Baxter wrote:
>> Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
> 
> I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.

You're worried about existing D1 code that relies on IFTI failing?

--bb

Walter Bright wrote:

> Bill Baxter wrote:
>> Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
> 
> I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.

In this case though the change can be interpreted as a bug right? So it is not a question of opinion on what should be moved but rather whether it is seen as a bug or a change. That's a pretty clear line.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Bill Baxter wrote:
> > Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
> I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.

I'm not sure I understand.  Could you please explain why this issue is a language change and not a bug?  The ticket was certainly submitted well prior to D 2.0's release.


Sean

Walter Bright wrote:
> I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.

Again, I reinforce that D versioning scheme is one of its most painful deficiencies. A three-component version numbering scheme (major.minor.patch) would best support this kind of development.

Such a change would land on the 1.x branch, without affecting the current 1.0.x branch, and eventually released as 1.1.0. No problem at all.

Soon, when the 2.x branch is stable enough for release as "stable", you will find that you won't be able to call it 2.anything, because there won't be any "reference point" inside the 2.x branch to call it stable, and the first "stable" release of 2.x will probably be called 3.0.

This should have been done long ago, since the first 1.x versions.

Good articles to read:
http://en.wikipedia.org/wiki/Software_versioning
http://www.advogato.org/article/40.html

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> Bill Baxter wrote:
>>> Any chance we'll be getting a backport of the fix to bug 493 in DMD
>>> 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
>> I understand your point, and I have mixed feelings about it. The trouble
>> is, it isn't a stable target if it gets language changes, and everyone
>> has a different idea on what should be moved from 2.0 to 1.0.
> 
> I'm not sure I understand.  Could you please explain why this issue is
> a language change and not a bug?  The ticket was certainly submitted
> well prior to D 2.0's release.

I think we just need to have a D1.1 release.  That would make everyone happy.  Like Miles just said, basically.

The majority of available code right now is D1 only.  So if you don't want to reinvent lots of wheels, your best bet is D1.  As most everyone knows, Tango is D1 only.  Probably the majority of long-timers here are still D1 only simply because if you have lots of code that works, moving all of it to an unstable D2 is not a very compelling proposition.

Let me put it this way.  I don't have the time or really the interest at this point to get my libs (OpenMeshD, Multiarray, Luigi) or the libs I depend on (DWT and Tango via that) updated to D2.  And beyond my dsource libs I have probably about an equal amount of application code written in D1.  I think probably a number of folks in the Tango team are in the same boat, and probably various others who got started with D1 and have been enjoying using it.

So does it make sense to leave this demographic of heavy D users behind with an aging feature set?

Ugh, I don't think I'm saying this well at all, but I can't spend any more time on this email, because I have to get back to my actual full-time job (writing D1 code, ATM).  Basically to sum it up, it seems to me like current development priorities neglect some of the most loyal D users, those who have been using it and writing large-ish libraries since D0 days.  A backward-compatible features-only D1.1 release would serve that, IMHO, important demographic.

--bb

Bill Baxter wrote:
> Sean Kelly wrote:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> Bill Baxter wrote:
>>>> Any chance we'll be getting a backport of the fix to bug 493 in DMD 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
>>> I understand your point, and I have mixed feelings about it. The trouble is, it isn't a stable target if it gets language changes, and everyone has a different idea on what should be moved from 2.0 to 1.0.
>>
>> I'm not sure I understand.  Could you please explain why this issue is a language change and not a bug?  The ticket was certainly submitted well prior to D 2.0's release.
> 
> I think we just need to have a D1.1 release.  That would make everyone happy.  Like Miles just said, basically.

Perhaps just using D2 as a testing version where new features are debugged before they're merged onto D1?  That might even be better, so that library makers have an opportunity to see a new feature coming in the future.

> The majority of available code right now is D1 only.  So if you don't want to reinvent lots of wheels, your best bet is D1.  As most everyone knows, Tango is D1 only.  Probably the majority of long-timers here are still D1 only simply because if you have lots of code that works, moving all of it to an unstable D2 is not a very compelling proposition.
> 
> Let me put it this way.  I don't have the time or really the interest at this point to get my libs (OpenMeshD, Multiarray, Luigi) or the libs I depend on (DWT and Tango via that) updated to D2.  And beyond my dsource libs I have probably about an equal amount of application code written in D1.  I think probably a number of folks in the Tango team are in the same boat, and probably various others who got started with D1 and have been enjoying using it.

I know there was an experimental branch a while back that was supposed to have worked with D2.  I don't know if it's still maintained.

> So does it make sense to leave this demographic of heavy D users behind with an aging feature set?
> 
> Ugh, I don't think I'm saying this well at all, but I can't spend any more time on this email, because I have to get back to my actual full-time job (writing D1 code, ATM).  Basically to sum it up, it seems to me like current development priorities neglect some of the most loyal D users, those who have been using it and writing large-ish libraries since D0 days.  A backward-compatible features-only D1.1 release would serve that, IMHO, important demographic.

Perhaps a Debian-like system, with an experimental, unstable, testing, and stable branch?  New stuff can be introduced in experimental, debugged to unstable, and then people can debate whether they like it or not as it phases from there into testing and finally stable.  Hopefully it'd slow down the rate of new compiler releases on the stable line, and make the changes between releases smaller, which would benefit library makers.

I'm not saying its the only system, or even the best, but if "the system" is going to change (which seems a mighty big assumption to me), it's something to at least consider.

Reply to Bill,

> A backward-compatible features-only D1.1 release would serve that,
> IMHO, important demographic.
> 

I'll second that.

I'd kinda like to see a version that is backwards compatible with 1.0 but allows in most anything that can be argued well as fixing an "issue" even if it is more than just a bug fix.

Reply to Chris,

> New stuff can be introduced in experimental, debugged to unstable, and
> then people can debate whether they like it or not as it phases from
> there into testing and finally stable.
> 

One problem, 2.0 has things that can't not be breaking changes. I don't ever want to see them in 1.0. I feel that is a distinction that must be maintained, and if it is, we need the 2.0 branch to play them in. With that IMHO, there won't be much reason to have the other levels.