View mode: basic / threaded / horizontal-split · Log in · Help
July 17, 2012
Re: D versionning
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
July 17, 2012
Re: D versionning
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.
July 17, 2012
Re: D versionning
"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
July 17, 2012
Re: D versionning
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.
July 17, 2012
Re: D versionning
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';
July 18, 2012
Re: D versionning
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
July 22, 2012
Re: D versionning
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.
July 22, 2012
Re: D versionning
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 :-)
July 23, 2012
Re: D versionning
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.
Next ›   Last »
11 12 13 14 15
Top | Discussion index | About this forum | D home