www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Changelog is messed up.

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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
Mar 04 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 04 2012
next sibling parent reply Don Clugston <dac nospam.com> writes:
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.
Mar 05 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 05 2012
parent reply Don Clugston <dac nospam.com> writes:
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?
Mar 05 2012
parent Don Clugston <dac nospam.com> writes:
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!
Mar 06 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f23458f73570704ba836599
Content-Type: text/plain; charset=ISO-8859-1

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

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 --e89a8f23458f73570704ba836599 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<= a href=3D"mailto:SeeWebsiteForEmail erdani.org">SeeWebsiteForEmail erdani.o= rg</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> <div class=3D"im">On 3/5/12 4:28 AM, Don Clugston wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Actually this is a release process issue.<br> The problem is that those pages are visible at all. Nobody should see<br> that, unless they pulled the docs from git.<br> That&#39;s not the docs for the current release, it&#39;s the docs for the = next<br> one. It&#39;s not just the changelog.<br> </blockquote> <br></div> Agreed. We do have a process in place for phobos and druntime, but not for = the main docs.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> <br> </font></span></blockquote></div><br><div>My opinion of how it should work = is there should be a &quot;next-release&quot; branch where all release spec= ific changes go. =A0master can be used for all changes that do not depend o= n the upcoming release. =A0Setting it up is pretty simple.</div> <div><br></div><div>=A0 =A0 git branch next-release # branch from master</d= iv><div>=A0 =A0 git push origin next-release # add branch to GitHub</div><d= iv><br></div><div>Repository contributors can just commit their release spe= cific changes to next-release and push. We=A0plebeians=A0can create pull re= quests that target the next-release branch (how to do this isn&#39;t all th= at intuitive on GitHub but it&#39;s pretty trivial to actually do:=A0<a hre= f=3D"http://help.github.com/send-pull-requests/">http://help.github.com/sen= d-pull-requests/</a>=A0).</div> <div><br></div><div>When a new version is about to be released just:</div><= div><br></div><div>=A0 =A0 git merge next-release # while master is checked= out</div><div><br></div><div>And all release specific changes will end up = on master from which you can deploy to the website.</div> <div><br></div><div>I&#39;ve actually got a pull request &lt;<a href=3D"htt= ps://github.com/D-Programming-Language/d-programming-language.org/pull/95">= https://github.com/D-Programming-Language/d-programming-language.org/pull/9= 5</a>&gt; that is exactly the right fit for this type of setup. =A0Pulling = it in to master means users would expect it to work but it won&#39;t until = after the next dmd release (which would hopefully include the companion pul= l request making the change). As it stands now I just have to be sure to ma= ke the pull conditions clear in the description which, frankly, doesn&#39;t= seem to work all that well (e.g., see the recent windows curl pulls that w= ere merged prematurely).</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> --e89a8f23458f73570704ba836599--
Mar 05 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d04083b052ceed304ba83ffc6
Content-Type: text/plain; charset=ISO-8859-1

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 --f46d04083b052ceed304ba83ffc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston <span dir=3D"ltr">&lt;<a href= =3D"mailto:dac nospam.com">dac nospam.com</a>&gt;</span> wrote:<br><div cla= ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 05/03/12 19:50, Brad Anderson wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu<br></div> &lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeW= ebsiteForEmail erdani.org</a> &lt;mailto:<a href=3D"mailto:SeeWebsiteForEma= il erdani.org" target=3D"_blank">SeeWebsiteForEmail <u></u>erdani.org</a>&g= t;&gt;<div> <div class=3D"h5"><br> wrote:<br> <br> =A0 =A0On 3/5/12 4:28 AM, Don Clugston wrote:<br> <br> =A0 =A0 =A0 =A0Actually this is a release process issue.<br> =A0 =A0 =A0 =A0The problem is that those pages are visible at all. Nobody<= br> =A0 =A0 =A0 =A0should see<br> =A0 =A0 =A0 =A0that, unless they pulled the docs from git.<br> =A0 =A0 =A0 =A0That&#39;s not the docs for the current release, it&#39;s t= he docs for<br> =A0 =A0 =A0 =A0the next<br> =A0 =A0 =A0 =A0one. It&#39;s not just the changelog.<br> <br> <br> =A0 =A0Agreed. We do have a process in place for phobos and druntime, but<= br> =A0 =A0not for the main docs.<br> <br> =A0 =A0Andrei<br> <br> <br></div></div><div class=3D"im"> My opinion of how it should work is there should be a &quot;next-release&qu= ot;<br> branch where all release specific changes go. =A0master can be used for<br> all changes that do not depend on the upcoming release. =A0Setting it up<br=

<br> =A0 =A0 git branch next-release # branch from master<br> =A0 =A0 git push origin next-release # add branch to GitHub<br> <br> Repository contributors can just commit their release specific changes<br> to next-release and push. We plebeians can create pull requests that<br> target the next-release branch (how to do this isn&#39;t all that intuitive= <br> on GitHub but it&#39;s pretty trivial to actually do:<br> <a href=3D"http://help.github.com/send-pull-requests/" target=3D"_blank">ht= tp://help.github.com/send-<u></u>pull-requests/</a> ).<br> <br> When a new version is about to be released just:<br> <br> =A0 =A0 git merge next-release # while master is checked out<br> <br> And all release specific changes will end up on master from which you<br> can deploy to the website.<br> </div></blockquote> <br> What should the autotester do?<br> </blockquote></div><br><div>The autotester isn&#39;t run on the website rep= ository (at least, not to my knowledge). =A0If you wanted to apply this sor= t of setup to the other repositories I think you&#39;d probably want it to = be a bit more solid with rigidly defined branch merging conditions rather t= han the flowing target of &#39;master&#39; on the website. =A0I use this mo= del at work with great success:=A0<a href=3D"http://nvie.com/posts/a-succes= sful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching= -model/</a></div> <div><br></div><div>In that approach you&#39;d just probably just run the a= utotester on &#39;develop&#39; since &#39;master&#39; almost always just re= presents the frozen codebase of the last release.</div><div><br></div><div> Regards,</div><div>Brad Anderson</div> --f46d04083b052ceed304ba83ffc6--
Mar 05 2012
prev sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f23458ff9341a04ba965126
Content-Type: text/plain; charset=ISO-8859-1

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

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 --e89a8f23458ff9341a04ba965126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 6, 2012 at 6:34 AM, Don Clugston <span dir=3D"ltr">&lt;<a href= =3D"mailto:dac nospam.com">dac nospam.com</a>&gt;</span> wrote:<br><div cla= ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 05/03/12 20:33, Brad Anderson wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Mon, Mar 5, 2012 at 12:10 PM, Don Clugston &lt;<a href=3D"mailto:dac nos= pam.com" target=3D"_blank">dac nospam.com</a><br></div><div class=3D"im"> &lt;mailto:<a href=3D"mailto:dac nospam.com" target=3D"_blank">dac nospam.c= om</a>&gt;&gt; wrote:<br> <br> =A0 =A0On 05/03/12 19:50, Brad Anderson wrote:<br> <br> =A0 =A0 =A0 =A0On Mon, Mar 5, 2012 at 5:50 AM, Andrei Alexandrescu<br> =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target= =3D"_blank">SeeWebsiteForEmail erdani.org</a><br> =A0 =A0 =A0 =A0&lt;mailto:<a href=3D"mailto:SeeWebsiteForEmail erdani.org"= target=3D"_blank">SeeWebsiteForEmail <u></u>erdani.org</a>&gt;<br></div> =A0 =A0 =A0 =A0&lt;mailto:<a href=3D"mailto:SeeWebsiteForEmail " target=3D= "_blank">SeeWebsiteForEmail </a>__<a href=3D"http://erdani.org" target=3D"_= blank">e<u></u>rdani.org</a><div><div class=3D"h5"><br> =A0 =A0 =A0 =A0&lt;mailto:<a href=3D"mailto:SeeWebsiteForEmail erdani.org"= target=3D"_blank">SeeWebsiteForEmail <u></u>erdani.org</a>&gt;&gt;&gt;<br> <br> =A0 =A0 =A0 =A0wrote:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0On 3/5/12 4:28 AM, Don Clugston wrote:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Actually this is a release process issue.<b= r> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The problem is that those pages are visible= at all. Nobody<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should see<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that, unless they pulled the docs from git.= <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That&#39;s not the docs for the current rel= ease, it&#39;s the<br> =A0 =A0 =A0 =A0docs for<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the next<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0one. It&#39;s not just the changelog.<br> <br> <br> =A0 =A0 =A0 =A0 =A0 =A0Agreed. We do have a process in place for phobos an= d<br> =A0 =A0 =A0 =A0druntime, but<br> =A0 =A0 =A0 =A0 =A0 =A0not for the main docs.<br> <br> =A0 =A0 =A0 =A0 =A0 =A0Andrei<br> <br> <br> =A0 =A0 =A0 =A0My opinion of how it should work is there should be a &quot= ;next-release&quot;<br> =A0 =A0 =A0 =A0branch where all release specific changes go. =A0master can= be<br> =A0 =A0 =A0 =A0used for<br> =A0 =A0 =A0 =A0all changes that do not depend on the upcoming release. =A0= Setting<br> =A0 =A0 =A0 =A0it up<br> =A0 =A0 =A0 =A0is pretty simple.<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 git branch next-release # branch from master<br> =A0 =A0 =A0 =A0 =A0 =A0 git push origin next-release # add branch to GitHu= b<br> <br> =A0 =A0 =A0 =A0Repository contributors can just commit their release speci= fic<br> =A0 =A0 =A0 =A0changes<br> =A0 =A0 =A0 =A0to next-release and push. We plebeians can create pull requ= ests that<br> =A0 =A0 =A0 =A0target the next-release branch (how to do this isn&#39;t al= l that<br> =A0 =A0 =A0 =A0intuitive<br> =A0 =A0 =A0 =A0on GitHub but it&#39;s pretty trivial to actually do:<br></= div></div> =A0 =A0 =A0 =A0<a href=3D"http://help.github.com/send-__pull-requests/" ta= rget=3D"_blank">http://help.github.com/send-__<u></u>pull-requests/</a><div= class=3D"im"><br> =A0 =A0 =A0 =A0&lt;<a href=3D"http://help.github.com/send-pull-requests/" = target=3D"_blank">http://help.github.com/send-<u></u>pull-requests/</a>&gt;= ).<br> <br> =A0 =A0 =A0 =A0When a new version is about to be released just:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 git merge next-release # while master is checked o= ut<br> <br> =A0 =A0 =A0 =A0And all release specific changes will end up on master from= <br> =A0 =A0 =A0 =A0which you<br> =A0 =A0 =A0 =A0can deploy to the website.<br> <br> <br> =A0 =A0What should the autotester do?<br> <br> <br></div><div class=3D"im"> The autotester isn&#39;t run on the website repository (at least, not to my= <br> knowledge). =A0 If you wanted to apply this sort of setup to the other<br> repositories<br> </div></blockquote> <br> I&#39;m assuming you would.<div class=3D"im"><br></div></blockquote><div><b= r></div><div>I don&#39;t really contribute to dmd enough that I&#39;d be af= fected by this change. =A0It&#39;s just friendly advise that the major cont= ributors like yourself might consider. I think it&#39;s a nice model though= . =A0That said, what you guys are currently doing seems to be working well = enough.</div> <div><br></div><div>I do, however, think the simplified version of it I pro= posed earlier would provide real value to the <a href=3D"http://dpl.org">dp= l.org</a> repository. =A0I have two pending pull requests that would benefi= t from being able to target a &#39;next-release&#39; (aka, &#39;develop&#39= ;) branch rather than the continually deployed from &#39;master&#39; branch= as they both rely on a merging of a dmd pull request I have pending.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <br> I think you&#39;d probably want it to be a bit more solid with<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> rigidly defined branch merging conditions rather than the flowing target<br=

br> success: <a href=3D"http://nvie.com/posts/a-successful-git-branching-model/= " target=3D"_blank">http://nvie.com/posts/a-<u></u>successful-git-branching= -<u></u>model/</a><br> <br> In that approach you&#39;d just probably just run the autotester on<br> &#39;develop&#39; since &#39;master&#39; almost always just represents the = frozen<br> codebase of the last release.<br> </blockquote> <br></div> The problem is &#39;almost always&#39;. The case where it doesn&#39;t is ju= st before you do a release, and it&#39;s the single most important time tha= t you need the autotester to be running!<br> </blockquote></div><br><div>The release branches shouldn&#39;t normally rec= eive changes that would break testing (typically just a version bump). =A0U= sually a=A0release- branch doesn&#39;t even leave the machine of the person= rolling it. =A0In practice I have had to make changes in release branches = so it&#39;s certainly something that can happen and not having the autotest= er for those=A0situations=A0would be a loss. Maybe the=A0autotester could b= e set up to run on release-* branches whenever one exists (and with higher = priority).</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> --e89a8f23458ff9341a04ba965126--
Mar 06 2012