View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/2012 08:02 PM, 1100110 wrote:
> A new module in Phobos is highly unlikely to break anything, So I would assume
> that this would count as a simple bug fix and be merged.

I don't really see that.  Yes, new functionality _per se_ is not going to break 
anything, but its implementation may be affected by breaking changes to D.  So, 
if you want to bring something new to Phobos, you may have to write 2 variants 
(for stable and dev) or else put up with your new functionality being excluded 
from stable until the breaking changes to D are merged in.
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
11/29/2012 11:08 PM, Joseph Rushton Wakeling пишет:
> On 11/28/2012 08:02 PM, 1100110 wrote:
>> A new module in Phobos is highly unlikely to break anything, So I
>> would assume
>> that this would count as a simple bug fix and be merged.
>
> I don't really see that.  Yes, new functionality _per se_ is not going
> to break anything, but its implementation may be affected by breaking
> changes to D.  So, if you want to bring something new to Phobos, you may
> have to write 2 variants (for stable and dev) or else put up with your
> new functionality being excluded from stable until the breaking changes
> to D are merged in.

I concur. Phobos is unstable in so much as compiler changes. So is true 
for the other libraries.
It would be my understanding that all project should rather use stable 
branch. Only those willing to try things out should use unstable and/or 
maintain 2 branches. But then unstable might not get enough test coverage.

-- 
Dmitry Olshansky
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Thu, Nov 29, 2012 at 08:08:08PM +0100, Joseph Rushton Wakeling wrote:
> On 11/28/2012 08:02 PM, 1100110 wrote:
> >A new module in Phobos is highly unlikely to break anything, So I
> >would assume that this would count as a simple bug fix and be merged.
> 
> I don't really see that.  Yes, new functionality _per se_ is not going
> to break anything, but its implementation may be affected by breaking
> changes to D.  So, if you want to bring something new to Phobos, you
> may have to write 2 variants (for stable and dev) or else put up with
> your new functionality being excluded from stable until the breaking
> changes to D are merged in.

Isn't this only necessary if the new feature depends on said breaking
changes? If not, it can be safely merged in. If it's a trivial change
like a syntax change, the stable maintainer can simply fix it by hand
and merge it in anyway.

The way I see it, is that after each release cycle, master is frozen for
beta testing, bugs are fixed, then master becomes the new stable (say,
by making a stable branch off the current master), then development
continues on master (apart from the new stable). Then there's no need to
reconcile any tweaks previously made to the previous stable branch,
since those will be distinct from the new stable.

If we do it this way, we can have actual, maintainable release branches.
For example:

(This is a hypothetical timeline:)
2013 Jan: master is deemed stable enough to be released, so we make a
new stable branch, call it stable-2.061. New development work continues
on master.

2013 Mar: new features are added to master. Stable maintainer decides
those changes are non-breaking and safe to merge in, so he cherry-picks
the changes and puts them into stable-2.061.

2013 Apr: breaking changes are made to master. Stable maintainer decides
*not* to pull them into stable-2.061.

2014 Jun: master is deemed almost ready for next release. Code is frozen
and extensive testing is done. Stable maintainer cherry-picks most
important fixes and backports them to stable-2.061.

2014 Jul: master is deemed releasable. Stable maintainer makes a new
branch from master, stable-2.062. New development continues on master.
The previous stable branch stable-2.061, is retired, or put in
maintenance mode (no longer actively maintained, but if there's a
critical fix in master that people are clamoring for, somebody can
cherry-pick those and put them in -- after making sure it's
non-breaking, of course).

etc..

The important thing to note here is that Walter & co. only ever works on
master. Whoever maintains the stable branches makes the decisions on
what to cherry-pick from master to put in the stable branch(es). (It
doesn't have to be exclusive, of course, ideally he would garner some
consensus on what should be included, but the point is that the core
developers shouldn't even have to worry about what goes into the stable
branches, they just work on master.)


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/29/2012 01:52 AM, Jonathan M Davis wrote:
> On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:
>> On 2012-11-29 01:50, Walter Bright wrote:
>>> Something has to be the default, and that dates back to when D was only
>>> implemented on 32 bit targets.
>>
>> How about defaulting to the architecture one is building on?
>
> I believe that that's what most applications do when you build them - at least
> in *nix land. There, it really doesn't make sense to assume either 32-bit or
> 64-bit.
>
> - Jonathan M Davis

Simply leaving MODEL= blank does just that.
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
> Isn't this only necessary if the new feature depends on said 
> breaking
> changes? If not, it can be safely merged in. If it's a trivial 
> change
> like a syntax change, the stable maintainer can simply fix it 
> by hand
> and merge it in anyway.
>

New code means new bugs. This is why most project use the 3 
numbers version. Eventually, if you add a new module to phobos, 
people use it, and even if you don't you ends up using it 
indirectly and you get the bugs.
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
> On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
>> Isn't this only necessary if the new feature depends on said 
>> breaking
>> changes? If not, it can be safely merged in. If it's a trivial 
>> change
>> like a syntax change, the stable maintainer can simply fix it 
>> by hand
>> and merge it in anyway.
>>
>
> New code means new bugs. This is why most project use the 3 
> numbers version. Eventually, if you add a new module to phobos, 
> people use it, and even if you don't you ends up using it 
> indirectly and you get the bugs.

The 3 number system is fine grained enough to do what we probably 
want.

If we use 3 version numbers like this: major.minor.revision, then

Incrementing "major" indicates a major release with breaking 
changes incorporated and/or new features added.

Incrementing "minor" indicates no breaking changes, no new 
features, but possibly new bugs were introduced due to the the 
changes that were made.

Incrementing "revision" indicates a bug fix only release.

We should also have 3 branches in principle, each corresponding 
to the 3 version numbers. One for stable, which receives only 
revision updates after major.minor is frozen, another for 
pre-stable and also for the "stable candidate" which frozen from 
new features, but uses same branch, and a 3rd for unstable, which 
eventually moves to pre-stable branch.

This is more or less how Debian seems to do it.

--rt
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-29 17:12, H. S. Teoh wrote:

> Didn't Walter already say that if somebody steps up to do it, he would
> endorse it?

Not what I've seen. At least not something more in those words.

-- 
/Jacob Carlborg
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg 
wrote:
> On 2012-11-29 17:12, H. S. Teoh wrote:
>
>> Didn't Walter already say that if somebody steps up to do it, 
>> he would
>> endorse it?
>
> Not what I've seen. At least not something more in those words.

What's needed is a core team of decision makers who have real 
decision making abilities. There's a reason why dictatorships 
usually perform poorly relative to other more advanced systems of 
decision making.

--rt
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-29 21:36, Rob T wrote:
> On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
>> On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
>>> Isn't this only necessary if the new feature depends on said breaking
>>> changes? If not, it can be safely merged in. If it's a trivial change
>>> like a syntax change, the stable maintainer can simply fix it by hand
>>> and merge it in anyway.
>>>
>>
>> New code means new bugs. This is why most project use the 3 numbers
>> version. Eventually, if you add a new module to phobos, people use it,
>> and even if you don't you ends up using it indirectly and you get the
>> bugs.
>
> The 3 number system is fine grained enough to do what we probably want.
>
> If we use 3 version numbers like this: major.minor.revision, then
>
> Incrementing "major" indicates a major release with breaking changes
> incorporated and/or new features added.
>
> Incrementing "minor" indicates no breaking changes, no new features, but
> possibly new bugs were introduced due to the the changes that were made.

That's not what I've heard. Minor could be new features, as long as they 
don't break anything. But that might be more for libraries, i.e. adding 
a new function.

-- 
/Jacob Carlborg
November 29, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg 
wrote:
> That's not what I've heard. Minor could be new features, as 
> long as they don't break anything. But that might be more for 
> libraries, i.e. adding a new function.

Exactly.
6 7 8 9 10 11
Top | Discussion index | About this forum | D home