On 2012-07-16 23:36, SomeDude wrote:

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

Yet again we need a compiler as a library :)

-- 
/Jacob Carlborg

On Tuesday, 17 July 2012 at 06:29:46 UTC, Jacob Carlborg wrote:
> On 2012-07-16 23:36, SomeDude wrote:
>
>> It's *not* textual search and replace. It's compiler checked semantic
>> refactoring.
>
> Yet again we need a compiler as a library :)

I find myself agreeing more and more.

"Chris NS" <ibisbasenji@gmail.com> writes:

> +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.

They haven't, on the contrary.

3.x is a release with new features
3.x.y is a bugfix release.

Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was confusing, because many people thought there was going to be a 2.8 at some point when there wasn't.

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula:

pi zz a

On 17/07/2012 06:37, 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.

Yeah sure. Nothing was released between 3.0 and 4.0 for instance. Not a single patch.

On 17 July 2012 12:05, Wouter Verhelst <wouter@grep.be> wrote:
> "Chris NS" <ibisbasenji@gmail.com> writes:
>
>> +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.
>
> They haven't, on the contrary.
>
> 3.x is a release with new features
> 3.x.y is a bugfix release.
>
> Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was confusing, because many people thought there was going to be a 2.8 at some point when there wasn't.
>

The reason for the move to 3.x is in the announcement.

http://lkml.org/lkml/2011/7/21/455

But yes, it simplifies the stable vs development kernel versioning.



-- 
Iain Buclaw

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

On Tuesday, 17 July 2012 at 18:12:28 UTC, Iain Buclaw wrote:
> On 17 July 2012 12:05, Wouter Verhelst <wouter@grep.be> wrote:
>> "Chris NS" <ibisbasenji@gmail.com> writes:
>>
>>> +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.
>>
>> They haven't, on the contrary.
>>
>> 3.x is a release with new features
>> 3.x.y is a bugfix release.
>>
>> Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was
>> confusing, because many people thought there was going to be a 2.8 at
>> some point when there wasn't.
>>
>
> The reason for the move to 3.x is in the announcement.
>
> http://lkml.org/lkml/2011/7/21/455
>
> But yes, it simplifies the stable vs development kernel versioning.

I don't recall where I first got my information, but clearly I was mistaken.  And I'm happy to have been so.  Maybe if I actually kept up more with the info on kernel releases I'd have known... alas.

-- Chris NS

On 7/16/12, Walter Bright <newshound2@digitalmars.com> wrote:
> 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.

Anyone know if MinGW and VC++ COFF object files are linkable? I might have even done this before without knowing, but I don't recall.

On 16/07/12 01:42, Jonathan M Davis wrote:
> 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.

... but is a switch to this versioning method really going to slow down the implementation of new features?

D is now stable enough (in terms of quality) and broad enough (in terms of features) for this scheme to be useful, so perhaps it's worth defining the "blocking" features that really _must_ be there before a switch in versioning style takes place.

I think that should probably be a minimal rather than maximal list, with the aim being to switch versioning style sooner rather than later.  It shouldn't have to wait on everything that TDPL lists -- how long is that going to take?

If you want the version number scheme to represent clearly the importance of the complete-TDPL milestone, how about instead bumping the MAJOR version number when it's done?  Yes, I know much has been said about "no D3", but this is a different and possibly useful definition of 3.0 :-)

On 16/07/12 23:33, 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. Going to v3
> would mean incrementing the 2. We have _no_ intention of doing that for years
> to come.

Just to note that, in the sense of making major changes to the language design, you're obviously right -- but I don't see the problem with bumping the major version number just to indicate that some key milestone has been passed (e.g. implementing in entirely the features described in TDPL).

That might even be a _good_ way of indicating to the wider development world that you have a really well-defined stable release.