November 29, 2012
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
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
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
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
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
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
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
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
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
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.