View mode: basic / threaded / horizontal-split · Log in · Help
March 04, 2012
D Changelog is messed up.
The D changelog shows that version 2.059 was released on the 16 of Feb. 
 I doubt it.  There is a broken download link for v2.059.  There are no 
bugfixes/enhancements/etc.

IIRC the top version is a placeholder for features/enhancements that 
will be in the next release.  If that's the case, it should SAY so, and 
there should be no download link for the presently non-existent release.

HTH
March 04, 2012
Re: D Changelog is messed up.
On 04/03/2012 15:07, Chad J wrote:
> The D changelog shows that version 2.059 was released on the 16 of Feb. I doubt it. There
> is a broken download link for v2.059. There are no bugfixes/enhancements/etc.
>
> IIRC the top version is a placeholder for features/enhancements that will be in the next
> release. If that's the case, it should SAY so, and there should be no download link for
> the presently non-existent release.

And moreover, there shouldn't be a release date unless release has actually been scheduled 
for that date.

Why the placeholder anyway?  If no changes for the version have yet been written, the 
section shouldn't be there.  If the point is to be a preview of what we will see in the 
next release, it should be formatted as such, with a heading such as "Coming in Version 
2.059" and each subheading left until there's actually something in it.

I can't see that the point is to make it quicker to add entries and to update the page to 
reflect the fact of release when it happens.  It only takes a second or two to delete <!-- 
--> once there is something to put in the section.

Stewart.
March 05, 2012
Re: D Changelog is messed up.
On 04/03/12 22:09, Stewart Gordon wrote:
> On 04/03/2012 15:07, Chad J wrote:
>> The D changelog shows that version 2.059 was released on the 16 of
>> Feb. I doubt it. There
>> is a broken download link for v2.059. There are no
>> bugfixes/enhancements/etc.
>>
>> IIRC the top version is a placeholder for features/enhancements that
>> will be in the next
>> release. If that's the case, it should SAY so, and there should be no
>> download link for
>> the presently non-existent release.
>
> And moreover, there shouldn't be a release date unless release has
> actually been scheduled for that date.
>
> Why the placeholder anyway? If no changes for the version have yet been
> written, the section shouldn't be there. If the point is to be a preview
> of what we will see in the next release, it should be formatted as such,
> with a heading such as "Coming in Version 2.059" and each subheading
> left until there's actually something in it.
>
> I can't see that the point is to make it quicker to add entries and to
> update the page to reflect the fact of release when it happens. It only
> takes a second or two to delete <!-- --> once there is something to put
> in the section.

Actually this is a release process issue.
The problem is that those pages are visible at all. Nobody should see 
that, unless they pulled the docs from git.
That's not the docs for the current release, it's the docs for the next 
one. It's not just the changelog.
March 05, 2012
Re: D Changelog is messed up.
On 3/5/12 4:28 AM, Don Clugston wrote:
> Actually this is a release process issue.
> The problem is that those pages are visible at all. Nobody should see
> that, unless they pulled the docs from git.
> That's not the docs for the current release, it's the docs for the next
> one. It's not just the changelog.

Agreed. We do have a process in place for phobos and druntime, but not 
for the main docs.

Andrei
March 05, 2012
Re: D Changelog is messed up.
On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu <
SeeWebsiteForEmail@erdani.org> wrote:

> On 3/5/12 4:28 AM, Don Clugston wrote:
>
>> Actually this is a release process issue.
>> The problem is that those pages are visible at all. Nobody should see
>> that, unless they pulled the docs from git.
>> That's not the docs for the current release, it's the docs for the next
>> one. It's not just the changelog.
>>
>
> Agreed. We do have a process in place for phobos and druntime, but not for
> the main docs.
>
> Andrei
>
>
My opinion of how it should work is there should be a "next-release" branch
where all release specific changes go.  master can be used for all changes
that do not depend on the upcoming release.  Setting it up is pretty simple.

   git branch next-release # branch from master
   git push origin next-release # add branch to GitHub

Repository contributors can just commit their release specific changes to
next-release and push. We plebeians can create pull requests that target
the next-release branch (how to do this isn't all that intuitive on GitHub
but it's pretty trivial to actually do:
http://help.github.com/send-pull-requests/ ).

When a new version is about to be released just:

   git merge next-release # while master is checked out

And all release specific changes will end up on master from which you can
deploy to the website.

I've actually got a pull request <
https://github.com/D-Programming-Language/d-programming-language.org/pull/95>
that is exactly the right fit for this type of setup.  Pulling it in to
master means users would expect it to work but it won't until after the
next dmd release (which would hopefully include the companion pull request
making the change). As it stands now I just have to be sure to make the
pull conditions clear in the description which, frankly, doesn't seem to
work all that well (e.g., see the recent windows curl pulls that were
merged prematurely).

Regards,
Brad Anderson
March 05, 2012
Re: D Changelog is messed up.
On 05/03/12 19:50, Brad Anderson wrote:
> On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 3/5/12 4:28 AM, Don Clugston wrote:
>
>         Actually this is a release process issue.
>         The problem is that those pages are visible at all. Nobody
>         should see
>         that, unless they pulled the docs from git.
>         That's not the docs for the current release, it's the docs for
>         the next
>         one. It's not just the changelog.
>
>
>     Agreed. We do have a process in place for phobos and druntime, but
>     not for the main docs.
>
>     Andrei
>
>
> My opinion of how it should work is there should be a "next-release"
> branch where all release specific changes go.  master can be used for
> all changes that do not depend on the upcoming release.  Setting it up
> is pretty simple.
>
>      git branch next-release # branch from master
>      git push origin next-release # add branch to GitHub
>
> Repository contributors can just commit their release specific changes
> to next-release and push. We plebeians can create pull requests that
> target the next-release branch (how to do this isn't all that intuitive
> on GitHub but it's pretty trivial to actually do:
> http://help.github.com/send-pull-requests/ ).
>
> When a new version is about to be released just:
>
>      git merge next-release # while master is checked out
>
> And all release specific changes will end up on master from which you
> can deploy to the website.

What should the autotester do?
March 05, 2012
Re: D Changelog is messed up.
On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <dac@nospam.com> wrote:

> On 05/03/12 19:50, Brad Anderson wrote:
>
>> On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>
>>
>> wrote:
>>
>>    On 3/5/12 4:28 AM, Don Clugston wrote:
>>
>>        Actually this is a release process issue.
>>        The problem is that those pages are visible at all. Nobody
>>        should see
>>        that, unless they pulled the docs from git.
>>        That's not the docs for the current release, it's the docs for
>>        the next
>>        one. It's not just the changelog.
>>
>>
>>    Agreed. We do have a process in place for phobos and druntime, but
>>    not for the main docs.
>>
>>    Andrei
>>
>>
>> My opinion of how it should work is there should be a "next-release"
>> branch where all release specific changes go.  master can be used for
>> all changes that do not depend on the upcoming release.  Setting it up
>> is pretty simple.
>>
>>     git branch next-release # branch from master
>>     git push origin next-release # add branch to GitHub
>>
>> Repository contributors can just commit their release specific changes
>> to next-release and push. We plebeians can create pull requests that
>> target the next-release branch (how to do this isn't all that intuitive
>> on GitHub but it's pretty trivial to actually do:
>> http://help.github.com/send-**pull-requests/<http://help.github.com/send-pull-requests/>).
>>
>> When a new version is about to be released just:
>>
>>     git merge next-release # while master is checked out
>>
>> And all release specific changes will end up on master from which you
>> can deploy to the website.
>>
>
> What should the autotester do?
>

The autotester isn't run on the website repository (at least, not to my
knowledge).  If you wanted to apply this sort of setup to the other
repositories I think you'd probably want it to be a bit more solid with
rigidly defined branch merging conditions rather than the flowing target of
'master' on the website.  I use this model at work with great success:
http://nvie.com/posts/a-successful-git-branching-model/

In that approach you'd just probably just run the autotester on 'develop'
since 'master' almost always just represents the frozen codebase of the
last release.

Regards,
Brad Anderson
March 06, 2012
Re: D Changelog is messed up.
On 05/03/12 20:33, Brad Anderson wrote:
> On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <dac@nospam.com
> <mailto:dac@nospam.com>> wrote:
>
>     On 05/03/12 19:50, Brad Anderson wrote:
>
>         On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu
>         <SeeWebsiteForEmail@erdani.org
>         <mailto:SeeWebsiteForEmail@erdani.org>
>         <mailto:SeeWebsiteForEmail@__erdani.org
>         <mailto:SeeWebsiteForEmail@erdani.org>>>
>
>         wrote:
>
>             On 3/5/12 4:28 AM, Don Clugston wrote:
>
>                 Actually this is a release process issue.
>                 The problem is that those pages are visible at all. Nobody
>                 should see
>                 that, unless they pulled the docs from git.
>                 That's not the docs for the current release, it's the
>         docs for
>                 the next
>                 one. It's not just the changelog.
>
>
>             Agreed. We do have a process in place for phobos and
>         druntime, but
>             not for the main docs.
>
>             Andrei
>
>
>         My opinion of how it should work is there should be a "next-release"
>         branch where all release specific changes go.  master can be
>         used for
>         all changes that do not depend on the upcoming release.  Setting
>         it up
>         is pretty simple.
>
>              git branch next-release # branch from master
>              git push origin next-release # add branch to GitHub
>
>         Repository contributors can just commit their release specific
>         changes
>         to next-release and push. We plebeians can create pull requests that
>         target the next-release branch (how to do this isn't all that
>         intuitive
>         on GitHub but it's pretty trivial to actually do:
>         http://help.github.com/send-__pull-requests/
>         <http://help.github.com/send-pull-requests/> ).
>
>         When a new version is about to be released just:
>
>              git merge next-release # while master is checked out
>
>         And all release specific changes will end up on master from
>         which you
>         can deploy to the website.
>
>
>     What should the autotester do?
>
>
> The autotester isn't run on the website repository (at least, not to my
> knowledge).   If you wanted to apply this sort of setup to the other
> repositories

I'm assuming you would.

I think you'd probably want it to be a bit more solid with
> rigidly defined branch merging conditions rather than the flowing target
> of 'master' on the website.  I use this model at work with great
> success: http://nvie.com/posts/a-successful-git-branching-model/
>
> In that approach you'd just probably just run the autotester on
> 'develop' since 'master' almost always just represents the frozen
> codebase of the last release.

The problem is 'almost always'. The case where it doesn't is just before 
you do a release, and it's the single most important time that you need 
the autotester to be running!
March 06, 2012
Re: D Changelog is messed up.
On Tue, Mar 6, 2012 at 6:34 AM, Don Clugston <dac@nospam.com> wrote:

> On 05/03/12 20:33, Brad Anderson wrote:
>
>> On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <dac@nospam.com
>> <mailto:dac@nospam.com>> wrote:
>>
>>    On 05/03/12 19:50, Brad Anderson wrote:
>>
>>        On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu
>>        <SeeWebsiteForEmail@erdani.org
>>        <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >
>>        <mailto:SeeWebsiteForEmail@__e**rdani.org <http://erdani.org>
>>
>>        <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>>
>>
>>        wrote:
>>
>>            On 3/5/12 4:28 AM, Don Clugston wrote:
>>
>>                Actually this is a release process issue.
>>                The problem is that those pages are visible at all. Nobody
>>                should see
>>                that, unless they pulled the docs from git.
>>                That's not the docs for the current release, it's the
>>        docs for
>>                the next
>>                one. It's not just the changelog.
>>
>>
>>            Agreed. We do have a process in place for phobos and
>>        druntime, but
>>            not for the main docs.
>>
>>            Andrei
>>
>>
>>        My opinion of how it should work is there should be a
>> "next-release"
>>        branch where all release specific changes go.  master can be
>>        used for
>>        all changes that do not depend on the upcoming release.  Setting
>>        it up
>>        is pretty simple.
>>
>>             git branch next-release # branch from master
>>             git push origin next-release # add branch to GitHub
>>
>>        Repository contributors can just commit their release specific
>>        changes
>>        to next-release and push. We plebeians can create pull requests
>> that
>>        target the next-release branch (how to do this isn't all that
>>        intuitive
>>        on GitHub but it's pretty trivial to actually do:
>>        http://help.github.com/send-__**pull-requests/<http://help.github.com/send-__pull-requests/>
>>
>>        <http://help.github.com/send-**pull-requests/<http://help.github.com/send-pull-requests/>>
>> ).
>>
>>        When a new version is about to be released just:
>>
>>             git merge next-release # while master is checked out
>>
>>        And all release specific changes will end up on master from
>>        which you
>>        can deploy to the website.
>>
>>
>>    What should the autotester do?
>>
>>
>> The autotester isn't run on the website repository (at least, not to my
>> knowledge).   If you wanted to apply this sort of setup to the other
>> repositories
>>
>
> I'm assuming you would.
>
>
I don't really contribute to dmd enough that I'd be affected by this
change.  It's just friendly advise that the major contributors like
yourself might consider. I think it's a nice model though.  That said, what
you guys are currently doing seems to be working well enough.

I do, however, think the simplified version of it I proposed earlier would
provide real value to the dpl.org repository.  I have two pending pull
requests that would benefit from being able to target a 'next-release'
(aka, 'develop') branch rather than the continually deployed from 'master'
branch as they both rely on a merging of a dmd pull request I have pending.


>
> I think you'd probably want it to be a bit more solid with
>
>> rigidly defined branch merging conditions rather than the flowing target
>> of 'master' on the website.  I use this model at work with great
>> success: http://nvie.com/posts/a-**successful-git-branching-**model/<http://nvie.com/posts/a-successful-git-branching-model/>
>>
>> In that approach you'd just probably just run the autotester on
>> 'develop' since 'master' almost always just represents the frozen
>> codebase of the last release.
>>
>
> The problem is 'almost always'. The case where it doesn't is just before
> you do a release, and it's the single most important time that you need the
> autotester to be running!
>

The release branches shouldn't normally receive changes that would break
testing (typically just a version bump).  Usually a release- branch doesn't
even leave the machine of the person rolling it.  In practice I have had to
make changes in release branches so it's certainly something that can
happen and not having the autotester for those situations would be a loss.
Maybe the autotester could be set up to run on release-* branches whenever
one exists (and with higher priority).

Regards,
Brad Anderson
Top | Discussion index | About this forum | D home