[dmd-beta] beta branch name
Daniel Murphy
yebblies at gmail.com
Fri Jan 24 06:04:21 PST 2014
I would really like
https://github.com/D-Programming-Language/dmd/pull/3061to go in this
release.
It's not a regression, but it's a nasty wrong-code bug and blocks ddmd on
linux64.
Does it seem reasonable to anyone?
On Sat, Jan 25, 2014 at 12:47 AM, Andrew Edwards <edwards.ac at gmail.com>wrote:
> The branch will be renamed tonight in preparation for building beta 2. I
> will make this change start building beta 2 at 10:00PM EST (UTC -5) so
> please ensure the auto tester is not using the release branch in order
> prevent any complications when it is renamed. Also just to verify that I am
> not causing any additional issues, the tags (aka version numbers) for the
> release will be as follows:
>
> 2.65.0-b2
>
> Obviously, this is another chance but mandatory to resolve issues with
> upgrading from installer packages on FreeBSD and Debian OSes.
>
> Following are the changes I've cherry-picked into the release branch since
> beta 1.
>
> DMD
> [REG2.061] Issue 11980 - startaddress pragma broken (pull request
> #3142)
> Issue 11974 - ICE(cast.c) Segfault with invalid assignment (pull
> request #3141)
> [REG2.065a] Issue 11966 - inout(const(char))[] doesn't convert to
> inout(char)[] (pull request #3138)
> fix Issue 11956 - dmd doesn't lookup /etc/dmd.conf (pull request #3128)
> Issue 11968 - ICE(expression.c) Crash when deleting __FILE__ (pull
> request #3139)
> Issue 11944 - ICE(expression.c) Assertion `f' failed. (pull request
> #3125)
> fix Issue 11922 - [REG2.065a] ICE on nonexistent identifier in
> templated auto method (pull request #3094)
> [REG2.065a] Issue 11924 - inout Variadic Template Parameters (pull
> request #3097)
> [REG2.065a] Issue 11896 - isVirtualMethod related GitHub HEAD
> regression (pull request #3104)
> [REG2.065a] Issue 11930 - Alias this not considered in is(T unused:
> U) matching (pull request #3105)
> [REG2.065a] Issue 11931 - Linkers "Symbol Undefined" again with dmd
> HEAD when -g specified (pull request #3107)
> [REG2.065a] Issue 11941 - Errors when appending to aggregate member
> array in CTFE (pull request #3112)
> [REG2.065a] Issue 11967 - ICE(parse.c) Parser crash (pull request
> #3137)
> [REG2.064] Issue 11965 - Segfault on garbage (pull request #3136)
> [REG2.065a] Issue 11963 - ICE(parse.c) Parser crash (pull request
> #3135)
>
> Druntime
> None
>
> Phobos
> Remove duplicate ArchiveMember.madeVersion() property.
>
> Installer
> Build the installer GUI for D2 on OS X (pull request #44)
> add "dustmite" binary on deb/rpm packages (pull request #43)
> don't zip .git* and .DS_Store files (pull request #42)
> fix expanding zip files created on Windows (pull request #41)
> cleanup leftover from merge conflict (pull request #40)
>
> dlang.org
> fix chmgen after renaming phobos.html => index.htm (pull request #480)
> Revert changelog.dd encoding to UTF-8 (pull request #478)
> Changelog: add notes about std.uni.byGrapheme and std.range.only (pull
> request #477)
> 2.065 changelog (pull request #476)
>
> tools
> None
>
> If important you are expected to be included are not on the list, please
> identify them so I can adjust accordingly.
>
>
>
> On 1/23/14, 11:03 PM, Brad Roberts wrote:
>
> On 1/23/14 2:17 PM, Brad Anderson wrote:
>
> On Thu, Jan 23, 2014 at 2:55 PM, Andrew Edwards <edwards.ac at gmail.com
> <mailto:edwards.ac at gmail.com> <edwards.ac at gmail.com>>
> wrote:
>
> On 1/23/14, 2:01 PM, Walter Bright wrote:
>
> I agree, I don't know what's wrong with what we had before:
>
> 1. All pull requests get merged to master
> 2. Create 2.065 branch
> 3. Cherry-pick from master to 2.065 as required
> 4. Tag 2.065.whatever as releases get done on that branch
>
> Easy, simple. All these other procedures seem like massive
> over-engineering to me.
>
> Good to go... I for one did not see either of you weigh in on the
> proposal when Brad Roberts
>
>
> Brad Anderson :P
>
> made it
> (
> http://forum.dlang.org/post/__CAFU1Uzpm4DBADOxMjcJ_Guj1=__T8BQ4nPb5OEbADNbUQDD2ijuQ@__mail.gmail.com
>
> <http://forum.dlang.org/post/CAFU1Uzpm4DBADOxMjcJ_Guj1=T8BQ4nPb5OEbADNbUQDD2ijuQ@mail.gmail.com><http://forum.dlang.org/post/CAFU1Uzpm4DBADOxMjcJ_Guj1=T8BQ4nPb5OEbADNbUQDD2ijuQ@mail.gmail.com>
> ).
> I decided to use it because, compared to the alternative of trying to
> convince volunteers to do
> something they do not want to, it would be much simpler for me to
> follow this scheme.
>
>
> I wish I would have thought to email Brad directly (sorry, Brad) to make
> sure he saw it and could
> weigh in. Especially since apart from you he's really the only other
> person that needs to change
> anything to adopt this workflow.
>
>
> To me there is no difference between the two processes, except the
> "we've always done it this
> way syndrome". Fixes are generated from release tags into a hotfix
> branch. Once the fix is
> released, we merge it back into master, remove the branch and move on.
> I am preparing both
> releases and hotpicks so I don't see any extra work being generated
> for the devs.
>
> The only chance I see on your parts is the need to change the tester
> scripts to point search for
> and test "hotfix" and "release" branches if they exist. I'm not the
> person doing that so I might
> have an overly simplified view of your processes but I really don't
> see the big deal.
>
>
> If Brad Roberts decides it's too hard for whatever reason we should be
> able to just change the
> workflow over to use a versioned branch name and dropping the step where
> the branch is deleted. Then
> the hotfix process would just checkout the versioned branch (and skip the
> delete as well). I like
> the tag and delete method better but we can't sacrifice the autotester for
> that.
>
>
> The problem is that as specified, _every_ fix requires also setting up
> builds in the auto-tester (regardless of who does it). That should be once
> per maintained version. Deleting and recreating is a waste of everyone's
> time.
>
> It's not just me that's affected. Anyone who wants to test releases as
> they're being built has to carefully track what branch to use when, which
> is tedious and a waste of time.
>
> Also, what if we decide to patch two past releases, does that happen
> serially, using the release branch name for each of the versions one at a
> time? Also stupid and a waste of time.
>
> Should I continue or is it obvious now?
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20140125/754ad76a/attachment.html>
More information about the dmd-beta
mailing list