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 <[email protected]
<mailto:[email protected]>>
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=t8bq4npb5oebadnbuqdd2i...@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
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
