Re: D 2.062 release
I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages. has this been done? it still seems the zip file doesn't contain it.
Re: D 2.062 release
And what about druntime.lib. Is it there? Or is it not needed? Dňa 27. 2. 2013 9:08 timotheecour wrote / napísal(a): I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages. has this been done? it still seems the zip file doesn't contain it.
Re: D 2.062 release
On Wednesday, February 27, 2013 09:30:24 Lubos Pintes wrote: And what about druntime.lib. Is it there? Or is it not needed? druntime is linked in as part of Phobos, so all you need is phobos.lib. It hasn't been packaged as a separate library for quite a while now. - Jonathan M Davis
Re: D 2.062 release
On 2/19/13 6:01 PM, Walter Bright wrote: On 2/18/2013 11:17 PM, Jacob Carlborg wrote: On 2013-02-18 21:58, Walter Bright wrote: I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages. Do you have an automated script for packing up the zip file? If not, this is the time to create one. We have seen this problem before, IIRC. Yes, I do use a script. The script has to copy all the correct files over to the right place. VERSION is a new file in a new place, and the script needed updating to copy that one. Automation is great, and I use it. But files appear, disappear, and change directory from release to release, and so the scripts must change as well. Maybe you can make the script uncompress the zip and build dmd... if it can build it, everything's fine :-)
Re: D 2.062 release
On Wednesday, 20 February 2013 at 06:39:12 UTC, Ali Çehreli wrote: On 02/19/2013 09:57 PM, Zach the Mystic wrote: Each developer who works on bugs and enhancements for a given release can keep a private journal, some small text file somewhere. +1 Although, I have seen this done in Bugzilla itself: Every bug has a field that contains what goes into the release notes. Any bug that is a part of a release must have that field filled in and reviewed. Pretty simple and works well. Ali That's my first '+1' ever! +1 to you, sir!
Re: D 2.062 release
On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: The dlang.org site isn't updated yet, but the downloads are there. The dlang changelog lists the release date as Jan 4, 2013, this is wrong. http://dlang.org/changelog.html#new2_062
Re: D 2.062 release
On 2/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? This is very helpful, thank you! P.S. it should cache the data to disk and read it from disk if the dates don't change from the last invocation. Querying bugzilla can take some time. Anyway can you make a pull for this to https://github.com/D-Programming-Language/tools/ ?
Re: D 2.062 release
19-Feb-2013 20:30, Andrej Mitrovic пишет: On 2/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? This is very helpful, thank you! P.S. it should cache the data to disk and read it from disk if the dates don't change from the last invocation. Querying bugzilla can take some time. Anyway can you make a pull for this to https://github.com/D-Programming-Language/tools/ ? I'm on it. I guess caching and other fancy stuff can be amended via the usual pull request path. I actually wanted it to get date/times of DMD/Phobos/Druntime versions from tags on Github (there is some REST api there). -- Dmitry Olshansky
Re: D 2.062 release
19-Feb-2013 21:00, Dmitry Olshansky пишет: 19-Feb-2013 20:30, Andrej Mitrovic пишет: On 2/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? This is very helpful, thank you! P.S. it should cache the data to disk and read it from disk if the dates don't change from the last invocation. Querying bugzilla can take some time. Anyway can you make a pull for this to https://github.com/D-Programming-Language/tools/ ? I'm on it. Done: https://github.com/D-Programming-Language/tools/pull/46 -- Dmitry Olshansky
Re: D 2.062 release
On 2/18/2013 11:17 PM, Jacob Carlborg wrote: On 2013-02-18 21:58, Walter Bright wrote: I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages. Do you have an automated script for packing up the zip file? If not, this is the time to create one. We have seen this problem before, IIRC. Yes, I do use a script. The script has to copy all the correct files over to the right place. VERSION is a new file in a new place, and the script needed updating to copy that one. Automation is great, and I use it. But files appear, disappear, and change directory from release to release, and so the scripts must change as well.
Re: D 2.062 release
On 2/19/2013 8:10 AM, Andrej Mitrovic wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: The dlang.org site isn't updated yet, but the downloads are there. The dlang changelog lists the release date as Jan 4, 2013, this is wrong. http://dlang.org/changelog.html#new2_062 Yes, that's because the web site was pushed from master rather than the 2.062 branch.
Re: D 2.062 release
On 2013-02-19 22:01, Walter Bright wrote: Yes, I do use a script. The script has to copy all the correct files over to the right place. VERSION is a new file in a new place, and the script needed updating to copy that one. Automation is great, and I use it. But files appear, disappear, and change directory from release to release, and so the scripts must change as well. Yeah, that's true. -- /Jacob Carlborg
Re: D 2.062 release
Yes, that's because the web site was pushed from master rather than the 2.062 branch. http://dlang.org/phobos/index.html#std Duplicates: std: Core library modules std.base64 Functions that operate on ASCII characters. std.base64 Encode/decode base64 format.
Re: D 2.062 release
On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I can see now there's a d.chm file in \bin. Walter that .chm file you're distributing in Windows\bin is v2.058 (judging by the changelog), or some other version, but it definitely isn't the latest because documentation is missing (e.g. getProtection trait). Why can't we open up the release process so we know exactly which scripts and procedure is used to make a release .zip? That way we can catch these bugs in time.
Re: D 2.062 release
On 2/19/2013 8:29 PM, Andrej Mitrovic wrote: On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I can see now there's a d.chm file in \bin. Walter that .chm file you're distributing in Windows\bin is v2.058 (judging by the changelog), or some other version, but it definitely isn't the latest because documentation is missing (e.g. getProtection trait). Why can't we open up the release process so we know exactly which scripts and procedure is used to make a release .zip? That way we can catch these bugs in time. It was in the beta.
Re: D 2.062 release
On Monday, 18 February 2013 at 01:31:47 UTC, Mike Parker wrote: But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. I guess I have two cents as well. Might as well throw them in! Each developer who works on bugs and enhancements for a given release can keep a private journal, some small text file somewhere. It only needs to note what that developer considers a highlight, something worth mentioning in a release notes format. When release time approaches, the manager solicits their notes from them, gives the whole thing a quick edit to avoid repeats, and you have your release notes. Now the release manager isn't responsible for remembering everything, just assembling it. The things which are the most interesting will probably be on their developers' minds anyway, so it's probably not too much punishment to ask them for their notes.
Re: D 2.062 release
On 02/19/2013 09:57 PM, Zach the Mystic wrote: Each developer who works on bugs and enhancements for a given release can keep a private journal, some small text file somewhere. +1 Although, I have seen this done in Bugzilla itself: Every bug has a field that contains what goes into the release notes. Any bug that is a part of a release must have that field filled in and reviewed. Pretty simple and works well. Ali
Re: D 2.062 release
On Monday, 18 February 2013 at 07:09:03 UTC, Walter Bright wrote: On 2/17/2013 10:27 PM, Nick Sabalausky wrote: I'm happy that http://dlang.org/changelog.html; no longer shows a link for a yet-to-be-released version of DMD (no sarcasm intended), but the release date listed for 2.062 is wrong. Probably because the site was generated from the master branch rather than the 2.062 branch (which has the correct date). One of the reasons which discourage committing to changelog is that it is placed in another repository, and that repository has strange building process. Maybe having a working copy of changelog in dmd (and phobos, druntime) repository (with requirement that each pull involves changelog as like a test case) can be an option?
Re: D 2.062 release
On 2013-02-18 08:31, Walter Bright wrote: As long as it isn't written in Ruby :-) I was not referring to what's usually called a scripting language. I was referring to a script, regardless of language. -- /Jacob Carlborg
Re: D 2.062 release
On Monday, 18 February 2013 at 07:31:53 UTC, Walter Bright wrote: As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. Here is a simpleton hack: ### RUBY require nokogiri require open-uri # provided the urls are given changes_new_features_url = http://...blah blah... d_runtime_fixes_url = http://...blah blah... phobos_fixes_url = http://...blah blah... def get_summaries(url) summaries = [] page = Nokogiri::HTML(open(url)) table = page.css(.bz_buglist) rows = table.css(tr) rows.each do |row| summary = row.css(td:last-child).text.strip summaries summary if !summary.empty? end summaries end puts \nChanges and New Features: puts get_summaries(changes_new_features_url) puts \nD Runtime Fixes: puts get_summaries(d_runtime_fixes_url) puts \nPhobos Fixes: puts get_summaries(phobos_fixes_url) ### END I guess the correct approach is to use Bugzilla's REST api, but its 1am... and this might be good enough?
Re: D 2.062 release
Steven Schveighoffer, el 17 de February a las 22:36 me escribiste: Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. +1 Having a dynamic changelog is a no-no. Is going against one of the most basic properties of a changelog. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- A veces quisiera ser un auto, para chocar como choco siendo humano, para romperme en mil pedazos.
Re: D 2.062 release
On 2013-02-18 10:02, Joshua Niehus wrote: On Monday, 18 February 2013 at 07:31:53 UTC, Walter Bright wrote: As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. Here is a simpleton hack: ### RUBY require nokogiri require open-uri # provided the urls are given changes_new_features_url = http://...blah blah... d_runtime_fixes_url = http://...blah blah... phobos_fixes_url = http://...blah blah... def get_summaries(url) summaries = [] page = Nokogiri::HTML(open(url)) table = page.css(.bz_buglist) rows = table.css(tr) rows.each do |row| summary = row.css(td:last-child).text.strip summaries summary if !summary.empty? end summaries end puts \nChanges and New Features: puts get_summaries(changes_new_features_url) puts \nD Runtime Fixes: puts get_summaries(d_runtime_fixes_url) puts \nPhobos Fixes: puts get_summaries(phobos_fixes_url) ### END I guess the correct approach is to use Bugzilla's REST api, but its 1am... and this might be good enough? This time it wasn't me :) -- /Jacob Carlborg
Re: D 2.062 release
18-Feb-2013 11:31, Walter Bright пишет: On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? -- Dmitry Olshansky
Re: D 2.062 release
Walter Bright, el 17 de February a las 19:54 me escribiste: If someone wants to step up and take charge of doing a better job with the changelog, I'm all for it. The old way was NOT a better job. It was usually left to me (and Jonathan) to try to cobble something together. When I was the only committer, I'd edit the changelog as things got changed. With the larger number of committers today, this got overlooked. The result was incomplete, inaccurate, and a lot of belated hey, you left out these changes after the release. Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. A missing changelog entry is like missing documentation or code comments, a pull request that doesn't update it shouldn't be merged! Making the changelog update go to just one person is the problem, that work should be distributed and the better person to do it is the one that made the change. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- For long you live and high you fly But only if you ride the tide And balanced on the biggest wave You race towards an early grave.
Re: D 2.062 release
On Monday, 18 February 2013 at 10:55:39 UTC, David Nadlinger wrote: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. David So maybe every changelog message should be stored in separated file. The release script would merge those according to the git history.
Re: D 2.062 release
Am Mon, 18 Feb 2013 10:05:10 +0100 schrieb Leandro Lucarella l...@llucax.com.ar: Steven Schveighoffer, el 17 de February a las 22:36 me escribiste: Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. +1 Having a dynamic changelog is a no-no. Is going against one of the most basic properties of a changelog. I think we need two things: A changelog. Should be automatically exported from bugzilla (but not a link to bugzilla, the changelog shouldn't change after the release), some projects even use the git commit log for this. Release notes describing the most important changes in the release as a concise, easy to read text.
Re: D 2.062 release
Am Mon, 18 Feb 2013 03:10:27 +0100 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: For the next release I propose that we get more involved in the release process: - We make an agreement on when exactly a release is made, without wondering when Walter might end up doing it himself. Maybe we should agree on a long-term release schedule. Here's an example for the next 10 releases with 6 weeks between every release and 2 additional minor releases per major release: http://wiki.dlang.org/User:Jpf/Release_Schedule The D script which was used to create the wiki page is linked from the wiki page. This makes it easy to change the duration between beta, rc and final releases, number of minor releases, etc.
Re: D 2.062 release
On Monday, 18 February 2013 at 10:55:39 UTC, David Nadlinger wrote: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. David Than maybe don't include changelog entry in a pull, but require that it is supplied with pull description as text, so that whoever mergers pull, separately pushes it to the branch? I would be nice if auto-tester could handle it automatically.
Re: D 2.062 release
dlangspec v2.062 in several formats: dlangspec.chm http://d-packages.googlecode.com/files/dlangspec.chm dlangspec.epub http://d-packages.googlecode.com/files/dlangspec.epub dlangspec.mobi http://d-packages.googlecode.com/files/dlangspec.mobi dlangspec.pdf http://d-packages.googlecode.com/files/dlangspec.pdf -- Jordi Sayol
Re: D 2.062 release
David Nadlinger, el 18 de February a las 11:55 me escribiste: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. Argh, I have the Merge button anyway (and it's Merge Art), but that's a different topic. An easy way to solve that is to add each changelog entry in a separate file, to avoid conflicts between changelog files, you could pick a schema like [date]-[user]-[some_id], for example: 20130118-llucax-fix9304.txt. Then all you need is a small script that put all the entries together that is executed when releasing. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Instead of doing a wash, I just keep buying underwear. My goal is to have over 360 pair. That way I only have to do wash once a year. -- George Constanza
Re: D 2.062 release
Steven Schveighoffer, el 18 de February a las 00:37 me escribiste: I propose that when you post the beta on the mailing list, you also post the reports of the fixed bugs and enhancements. Then people can edit the descriptions before the release. Then I think after the release, the descriptions should be locked, and the bugs cannot be reopened. Please, don't do that, is the changelog what's broken, don't break the issue tracker too to try to make a changelog out of it! I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Decile que ponga rails generate tp_prof_fiuba en la consola y en una semana se recibe. -- Mazzi, filósofo estilista
Re: D 2.062 release
18-Feb-2013 17:22, Leandro Lucarella пишет: I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... Or instead somebody just has to take time and write down 10 most important things in new release. Add this task to release manager role. *That's* what interesting not pushing more grunt work on contributors that basically doesn't work at all. Other then this a small script to expand the bugzilla entries into a webpage (just like before title + link to bugzilla). -- Dmitry Olshansky
Re: D 2.062 release
On Mon, 18 Feb 2013 01:31:47 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 10:18 PM, Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. This statement is provably false. See here: http://dlang.org/changelog.html#new2_057 First element in the changelog is: Better use of XMM registers in 64 bit targets. Searching in bugzilla I get: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedshort_desc=Better%20use%20of%20XMMshort_desc_type=substring Zero issues found This text cannot have been copy and pasted out of bugzilla. These 'changelog-like' messages are what I miss. For a list of bugs fixed, sure, just give me a report, I don't care (better if the report is extracted into the changelog instead of a query into a live database). But I want the new/changed features list back. -Steve
Re: D 2.062 release
18-Feb-2013 13:18, Dmitry Olshansky пишет: 18-Feb-2013 11:31, Walter Bright пишет: On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? The output of said D script for 2.062 is: $(DMDBUGSFIXED $(LI $(BUGZILLA 1369): Unable to find 'this' in __traits(getMember)) $(LI $(BUGZILLA 1730): Bogus error message calling a non-const struct method on a const struct reference) $(LI $(BUGZILLA 1841): Closure detection doesn't work when variable is used in a nested function) $(LI $(BUGZILLA 2452): Unimplemented method errors should show function overload) $(LI $(BUGZILLA 2630): ddoc should be able to document unittests) $(LI $(BUGZILLA 3321): debug flags) $(LI $(BUGZILLA 3404): JSON output should retain original alias names) $(LI $(BUGZILLA 3466): Wrong JSON output for templated classes, structs, and interfaces) $(LI $(BUGZILLA 4178): destructor missing in JSON output) $(LI $(BUGZILLA 4194): Attributes included in JSON output) $(LI $(BUGZILLA 4269): Regression(2.031): invalid type accepted if evaluated while errors are gagged) $(LI $(BUGZILLA 4477): JSON output for function definitions includes insufficient type information) $(LI $(BUGZILLA 4478): JSON output omits import statements) $(LI $(BUGZILLA 4540): Better error message for wrong switch type) $(LI $(BUGZILLA 5168): String enums don't work with -g compiler switch) $(LI $(BUGZILLA 5461): Invalid declaration for auto functions in .di files generated by DMD -H) $(LI $(BUGZILLA 5529): std.system.endian for pure functions?) $(LI $(BUGZILLA 5893): Allow simple aliases for operator overloading) $(LI $(BUGZILLA 5933): Cannot retrieve the return type of an auto-return member function) $(LI $(BUGZILLA 5978): ICE(mtype.c) when calling __traits(parent) on the child of an anonymous function.) $(LI $(BUGZILLA 6057): Problem with defining enum in function) $(LI $(BUGZILLA 6171): rdmd: cache dependency file to improve startup time [patch]) $(LI $(BUGZILLA 6319): debug's relaxed purity does not apply to nested scopes) $(LI $(BUGZILLA 6332): Auto-return function cannot be inferred as @safe) $(LI $(BUGZILLA 6408): string[].init gives a wrong type) $(LI $(BUGZILLA 6538): ICE(mangle.c) Invalid template constraints) $(LI $(BUGZILLA 6552): Wrong fallthrough warning for CaseRange) $(LI $(BUGZILLA 6652): foreach parameter with number range is always ref) $(LI $(BUGZILLA 6708): immutable ref implicit cast to const ref) $(LI $(BUGZILLA 6743): ICE(mars.c) attempting to compile an exe file) $(LI $(BUGZILLA 6833): Floating point literals lose fractional part in headers) $(LI $(BUGZILLA 6873): Multiple storage class is not allowed on template argument) $(LI $(BUGZILLA 6902): Different pure nothrow int() types) $(LI $(BUGZILLA 6905): ref acts as auto ref when return type is missing) $(LI $(BUGZILLA 6962): Wrong Code With Scope Exit and Array Parameter, only with -O) $(LI $(BUGZILLA 6963): pure/nothrow inference doesn't work for function pointers) $(LI $(BUGZILLA 7152): Can't assign null to default argument) $(LI $(BUGZILLA 7159): Forward reference when casting auto return method) $(LI $(BUGZILLA 7408): traits compiles fails for built-in properties of template instances) $(LI $(BUGZILLA 7420): Duplicate cannot be read at compile time error messages) $(LI $(BUGZILLA 7585): functions in templates inferred as delegate) $(LI $(BUGZILLA 7740): unicodeProperties cannot be read at compile time for ctRegex) $(LI $(BUGZILLA 7950): Type tuples are incorrectly flattened in base type list of interface) $(LI $(BUGZILLA 8053): Recursive alias this causes infinite loop) $(LI $(BUGZILLA 8105): Implement in ref) $(LI $(BUGZILLA 8128): unittest blocks should be allowed in interfaces) $(LI $(BUGZILLA 8152): Linking C library causes Seg-fault) $(LI $(BUGZILLA 8153): Warning about toHash signature is incorrect on x86_64) $(LI $(BUGZILLA 8504): Template attribute inferrence doesn't work) $(LI $(BUGZILLA 8583): [64 bit] AA ushort[dchar] byValue range is corrupted on x86_64) $(LI $(BUGZILLA 8631): illegal overrides accepted) $(LI $(BUGZILLA 8717): `private` and `protected` restrict member usage in same module) $(LI $(BUGZILLA 8742): Anonymous nested class derived from another nested class makes DMD crash) $(LI $(BUGZILLA 8763): struct
Re: D 2.062 release
Must be a problem with mobile Chrome then. Probably not specific to the new change log handling. In chrome that entire content pane has a tendency to disappear. --bb Sent from my Android. On Feb 17, 2013 11:20 PM, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 5:40 PM, Bill Baxter wrote: The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). I tried it on my ipod with Safari. Both changelog.html and bugzilla render fine, though it helps to turn the ipod sideways to get 'landscape' mode.
Re: D 2.062 release
On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Has anyone even tested the release package? I get make: *** No rule to make target `../VERSION', needed by `verstr.h'. Stop. during building of dmd. People in #d report the same. It can't work, the file isn't even in the package.
Re: D 2.062 release
Am Sun, 17 Feb 2013 17:02:20 -0800 schrieb Walter Bright newshou...@digitalmars.com: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I didn't read the whole thread now. Just reporting that the .zip package cannot be compiled due to missing VERSION file and that all the Phobos documentation now has empty Examples: sections (which I thought was already fixed). -- Marco
Re: D 2.062 release
On Monday, February 18, 2013 18:43:37 Dmitry Olshansky wrote: 18-Feb-2013 17:22, Leandro Lucarella пишет: I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... Or instead somebody just has to take time and write down 10 most important things in new release. Add this task to release manager role. *That's* what interesting not pushing more grunt work on contributors that basically doesn't work at all. Other then this a small script to expand the bugzilla entries into a webpage (just like before title + link to bugzilla). Exactly. It would be nice to have the list of bug fixes and whatnot listed on the page directly rather than linked to, but having that managed automatically is great. The real problem is that we need a set of release notes at the top which lists the important changes. That just means that someone needs to take the time to write that up for each release. Updating the changelog manually is not only broken because stuff gets missed, but it's broken because it causes merge problems if you merge in the changelog changes at the same time as the commit. We don't need all of that extra grunt work. We just need the release notes section to be written by someone (or someones) in preparation for the release. - Jonathan M Davis
Re: D 2.062 release
On 2/18/2013 8:47 AM, Bill Baxter wrote: Must be a problem with mobile Chrome then. Probably not specific to the new change log handling. In chrome that entire content pane has a tendency to disappear. I'm still not sure if you're referring to the changelog.html page or the bugzilla page.
Re: D 2.062 release
On 2/18/2013 9:02 AM, Sven-Hendrik Haase wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Has anyone even tested the release package? I get make: *** No rule to make target `../VERSION', needed by `verstr.h'. Stop. during building of dmd. People in #d report the same. It can't work, the file isn't even in the package. I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages.
Re: D 2.062 release
On Monday, 18 February 2013 at 01:31:47 UTC, Mike Parker wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: I've lost the motivation to even look at the changelog now. +1
Re: D 2.062 release
On 2/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I agree we need to improve on this. One way to achieve that, seeing as marketing is not Walter's focus, is to denote a release czar who has that particular task around releases. Andrej, would you want to try that role? How about I write how a release would look like for 2.062 (a mockup), and if we're all fond of it we can base this on the upcoming release? That way we don't have to argue days before a release on what the release should look like.
Re: D 2.062 release
On 2/19/13, Brad Roberts bra...@puremagic.com wrote: How about writing one for 2.062 that can be inserted into the change log instead of the current links rather than a mockup that might represent what a change log might look like? Yes. I'll get to it and make a pull request once it's ready.
Re: D 2.062 release
On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html Argh the chm generation is awful now. I mean when I try to generate the .chm file myself. I can see now there's a d.chm file in \bin. It doesn't have loading issues, however there is no styling in the .chm file.
Re: D 2.062 release
On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Error while processing file: .\spec.html object.Error: Access Violation I've filed it: http://d.puremagic.com/issues/show_bug.cgi?id=9533
Re: D 2.062 release
On 2/18/2013 1:18 AM, Dmitry Olshansky wrote: This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? Please add this to the tools repository on github.
Re: D 2.062 release
On 2/18/2013 6:46 AM, Steven Schveighoffer wrote: On Mon, 18 Feb 2013 01:31:47 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 10:18 PM, Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. This statement is provably false. See here: http://dlang.org/changelog.html#new2_057 First element in the changelog is: Better use of XMM registers in 64 bit targets. Searching in bugzilla I get: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedshort_desc=Better%20use%20of%20XMMshort_desc_type=substring Zero issues found This text cannot have been copy and pasted out of bugzilla. Part of the idea of the new system is that all of those one-liners become one-liners in bugzilla.
Re: D 2.062 release
Personally, I just wish there was a quick blurb at the top of the changelog indicating the highlights of this release. For example, with 2.058, the very first two lines of the changelog were: Add new = lambda syntax. Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0. You can look at that and decide Awesome, new lambda syntax and UFCS!. You get a quick 10-20 lines indicating what you need to know about that release, what's interesting about it, and what the new features or most important bug fixes were. For the people who care, you can then see bug fixes / larger list of changes at the bottom (I personally don't have a preference as to whether they'd be on the same page or just a bugzilla link). However the really important thing is the quick blurb at the top. For example, with this release, something about how 'in ref' is now supported, how you can document unittests and have them appear with the documentation of the above symbol, improved JSON output, and unittests being allowed in interfaces. This is just a quick 10 line overview of some of the highlights of this release. Not necessarily just new features either. For example, if example bug#314 was fixed, there is absolutely no way I would know about it given that it's buried in the list of bug fixes, even though it has affected almost every single D user at one point and would definitely be considered a highlight.
Re: D 2.062 release
On 2013-02-19 07:25, Kapps wrote: Personally, I just wish there was a quick blurb at the top of the changelog indicating the highlights of this release. For example, with 2.058, the very first two lines of the changelog were: Add new = lambda syntax. Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0. You can look at that and decide Awesome, new lambda syntax and UFCS!. You get a quick 10-20 lines indicating what you need to know about that release, what's interesting about it, and what the new features or most important bug fixes were. For the people who care, you can then see bug fixes / larger list of changes at the bottom (I personally don't have a preference as to whether they'd be on the same page or just a bugzilla link). However the really important thing is the quick blurb at the top. For example, with this release, something about how 'in ref' is now supported, how you can document unittests and have them appear with the documentation of the above symbol, improved JSON output, and unittests being allowed in interfaces. This is just a quick 10 line overview of some of the highlights of this release. Not necessarily just new features either. For example, if example bug#314 was fixed, there is absolutely no way I would know about it given that it's buried in the list of bug fixes, even though it has affected almost every single D user at one point and would definitely be considered a highlight. I agree. I think documenting mixins was added in this release. -- /Jacob Carlborg
Re: D 2.062 release
On 2/17/2013 5:07 PM, Andrej Mitrovic wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. The zip download is broken: http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/2013/dmd.2.062.zip It's there now (along with the other variations of the packaging).
Re: D 2.062 release
On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release.
Re: D 2.062 release
The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). --bb Sent from my Android. On Feb 17, 2013 5:25 PM, Brad Roberts bra...@puremagic.com wrote: On 2/17/2013 5:07 PM, Andrej Mitrovic wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. The zip download is broken: http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/2013/dmd.2.062.zip It's there now (along with the other variations of the packaging).
Re: D 2.062 release
On Sun, 17 Feb 2013 20:31:45 -0500, Mike Parker aldac...@gmail.com wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. +1 -Steve
Re: D 2.062 release
On 2/17/2013 5:31 PM, Mike Parker wrote: Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. It wasn't before, either. It was a list sorted by bugzilla number - no other sort - and it's the same now. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. I'm sorry, I'm baffled at this. The ordering and the information is exactly the same - a list of issue numbers and the issue title.
Re: D 2.062 release
On 2/17/2013 5:40 PM, Bill Baxter wrote: The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). The changelog.html uses the same template as the rest of the dconf.org site.
Re: D 2.062 release
On 2/18/13, Mike Parker aldac...@gmail.com wrote: But I just want to throw in my 2 cents about the new changelog format. Not just the changelog, but this release announcement too. Two sentences, without any information about what is being released, who is involved, and a short few sentences on what's new. Very cold, and a complete marketing failure. For the next release I propose that we get more involved in the release process: - We make an agreement on when exactly a release is made, without wondering when Walter might end up doing it himself. - We maintain a list of open pull requests which have to be merged before a release is made (we can even use DWiki for this). We could also maintain a list of bugs which should be the focus of each upcoming release. - Next to the buzilla queries in the changelog we should write a list of changes in some informative manner (split up categorically e.g. bugfixes, new syntax, new phobos features, etc), what's new, how some bug may or may not affect its users and how they can work around any code breakage. - We split up the changelog so it isn't one gigantic page. - We write an announcement post to NG that's short but informative, making sure we give a thanks to our users, reporters, maintainers and bug fixers (I'm not saying list all of their names but just a general thank you note). - We make sure the announcement can be seen on the dlang.org front page! For some examples of how other language maintainers make announcements, see: http://mail.python.org/pipermail/python-announce-list/2012-September/009630.html http://dev.perl.org/perl5/news/2012/perl-5.16.0.html https://groups.google.com/forum/#!topic/scala-announce/cRNUEBmcZYw
Re: D 2.062 release
On Sun, 17 Feb 2013 20:55:21 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 5:31 PM, Mike Parker wrote: Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. It wasn't before, either. It was a list sorted by bugzilla number - no other sort - and it's the same now. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. I'm sorry, I'm baffled at this. The ordering and the information is exactly the same - a list of issue numbers and the issue title. Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Now, I'll sure love the new replace compile error, the missing Duration.max, and the need to document extern as much as the next guy, but can we get some better descriptions? ;) Some of the descriptions work well for a changelog, but many of them don't. Even ones that are clear that they were a new feature are worded awkwardly. For example, the new feature std.random.uniform!Enum should return random enum member should really be std.random.uniform!Enum now returns a random enum member instead of a random integer The 'bugs fixed' report can be a link to bugzilla, but being able to read it inline on the changelog would be a good improvement. These are going to be static lists, there is no need to query them from a DB every time. -Steve
Re: D 2.062 release
Walter Bright: I'm sorry, I'm baffled at this. I too prefer the precedent style of the changelog. Sometimes the reality is more complex than the frame you try to shove it in :-) Reality of human brains is complex. Bye, bearophile
Re: D 2.062 release
Walter Bright: I'm sorry, I'm baffled at this. I read bugzilla entries all day long, but I think as a release page information that page gives too much information (the Sev Pri OS Assignee Status Resolution columns) that's just distracting noise. Sometimes giving less is more. Bye, bearophile
Re: D 2.062 release
On 2/17/13 9:10 PM, Andrej Mitrovic wrote: On 2/18/13, Mike Parkeraldac...@gmail.com wrote: But I just want to throw in my 2 cents about the new changelog format. Not just the changelog, but this release announcement too. Two sentences, without any information about what is being released, who is involved, and a short few sentences on what's new. Very cold, and a complete marketing failure. I agree we need to improve on this. One way to achieve that, seeing as marketing is not Walter's focus, is to denote a release czar who has that particular task around releases. Andrej, would you want to try that role? Andrei
Re: D 2.062 release
On 2/17/13 8:02 PM, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I've updated the website, too. Enjoy! Andrei
Re: D 2.062 release
On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. Also, anyone can go in and change the bugzilla issue titles to make them more readable.
Re: D 2.062 release
On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std.regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. A good first step would be to examine the bugzilla reports that will be listed as new features (should be easy since it's a report that's already being used by the web site), and change the descriptions to real useful enhancement descriptions before the release. But I think the release needs a hard copy of these descriptions. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. -Steve
Re: D 2.062 release
On 2/17/2013 7:36 PM, Steven Schveighoffer wrote: On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std. regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. All that's necessary is to edit the title description. I've done that on a few of them. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. It is no more or less effort to fix the bugzilla titles than it is to edit the changelog. A good first step would be to examine the bugzilla reports that will be listed as new features (should be easy since it's a report that's already being used by the web site), and change the descriptions to real useful enhancement descriptions before the release. But I think the release needs a hard copy of these descriptions. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. With the new system, all changes should have a bugzilla entry for them. With the old, there were occasional vacuous statements in the changelog with no links to any discussion or just what it was. Look at the changelogs that list an issue number. All of them have the exact same text as the corresponding bugzilla title. I know they're the same because: 1. people requested that they be the same 2. I created them using cut paste With bugzilla entries for each item in the changelog, you have: 1. a title 2. discussion 3. link to the pull request that shows the code that changed to implement it Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. I know that there is the potential for malicious behavior, but thankfully we haven't seen any of that. If we do, we'll have to restrict write access to bugzilla. That'll be a sad day. If someone wants to step up and take charge of doing a better job with the changelog, I'm all for it. The old way was NOT a better job. It was usually left to me (and Jonathan) to try to cobble something together. When I was the only committer, I'd edit the changelog as things got changed. With the larger number of committers today, this got overlooked. The result was incomplete, inaccurate, and a lot of belated hey, you left out these changes after the release.
Re: D 2.062 release
On Sun, 17 Feb 2013 22:54:54 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 7:36 PM, Steven Schveighoffer wrote: On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std. regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. All that's necessary is to edit the title description. I've done that on a few of them. Sure, so we need someone to do that. But a changelog that is *potentially* informative is not actually informative now. The previous changelogs were informative. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. It is no more or less effort to fix the bugzilla titles than it is to edit the changelog. Who edited the changelog before? Can that person or people edit the bugzilla entries? I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. With the new system, all changes should have a bugzilla entry for them. With the old, there were occasional vacuous statements in the changelog with no links to any discussion or just what it was. I found the statements in the changelog not requiring extra research. Yes, it is important to have background for the reasoning of a change. I agree that the statements should have any referenced bugzilla reports included. But if you are not interested in the background for why a change was made, or the discussion that resulted in the change, or the original concern that led to the change, it is tedious to have to sift through that information to get to the conclusion. Most changes can be summarized in one sentence for the casual observer. In the past, I could scan the changelog, look for interesting changes, and the ones I was more interested in, I could drill down into. A bug is a bug, and saying we fixed this bug, here was the original description: xxx is fine. But new/changed features should have a full explanation and, if necessary, examples right in the description. Look at the changelogs that list an issue number. All of them have the exact same text as the corresponding bugzilla title. Right, and for bugs, that is fine. For bugs where the bugzilla description completely describes the change, that is fine. For feature enhancements like std.array.replace compile error (string and immutable string), I can't determine anything from that, you might as well have just said Bug 1234. With bugzilla entries for each item in the changelog, you have: 1. a title 2. discussion 3. link to the pull request that shows the code that changed to implement it I don't disagree bug links should be in the changelog, nor do I really fundamentally disagree that replacing the changelog with a bugzilla query is a valid changelog. What I disagree with though is the position that the previous changelog entries that were hand-written were no more informative than the current changelog. Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. I know that there is the potential for malicious behavior, but thankfully we haven't seen any of that. If we do, we'll have to restrict write access to bugzilla. That'll be a sad day. It doesn't have to be deliberately malicious behavior. People think bug reports are bug reports, I've seen several cases where bug reports are re-opened with an issue that is
Re: D 2.062 release
On 2/17/2013 9:37 PM, Steven Schveighoffer wrote: I propose that when you post the beta on the mailing list, you also post the reports of the fixed bugs and enhancements. Then people can edit the descriptions before the release. Then I think after the release, the descriptions should be locked, and the bugs cannot be reopened. The changelog is up on github, anyone can create a pull request for it. I invite you to.
Re: D 2.062 release
On Sun, 17 Feb 2013 18:44:18 -0800 Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. First of all, it's now split across four separate pages. Five if you count the page that doesn't actually contain any real information besides the four links. Secondly, the new format contains loads of superfluous data. Did the old changelog page dedicate over 1/3 of the page to rows and rows and rows of nor P2 All No Owner RESO FIXE, none of wehich belongs in a changelog? No it didn't. Definitely NOT the exact same text. Third, the old changelog's formatting was overall jsut far more readable. Fourth, as people said, the wording in the old changelog was much more appropriate for a changelog. Yea, people can update the titles of the zilla entries: Thus making them *very strangely* worded for archived bug reports. But does that actually happen? No (And I'm unconviunced that it even should). Did changelog-appropriate wording happen with the old changelog? Yes. DO you really think that so many people would be so annoyed with the new format if there *weren't* real problems with it?
Re: D 2.062 release
On Sun, 17 Feb 2013 17:56:20 -0800 Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 5:40 PM, Bill Baxter wrote: The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). The changelog.html uses the same template as the rest of the dconf.org site. !-- Really? Not to be an ass, but how the *(^ is that fact going to help him read the changelog on his mobile when the changelog info *isn't on that page*? -- Erm, I mean, he's talking about the bugzilla-hosted pages with the actual changelog information.
Re: D 2.062 release
On Sun, 17 Feb 2013 21:30:27 -0500 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/17/13 8:02 PM, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I've updated the website, too. Enjoy! I'm happy that http://dlang.org/changelog.html; no longer shows a link for a yet-to-be-released version of DMD (no sarcasm intended), but the release date listed for 2.062 is wrong.
Re: D 2.062 release
On 2/17/2013 10:18 PM, Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. DO you really think that so many people would be so annoyed with the new format if there *weren't* real problems with it? I was far more annoyed at the very inaccurate incomplete changelogs caused by it being edited by hand. Obviously, the formatting of the changelog is important to several people. I seriously invite you to issue pull requests for it - it's all here: https://github.com/D-Programming-Language/d-programming-language.org
Re: D 2.062 release
On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Thank you Walter Bright. I appreciate your work.
Re: D 2.062 release
On 2/17/2013 10:27 PM, Nick Sabalausky wrote: I'm happy that http://dlang.org/changelog.html; no longer shows a link for a yet-to-be-released version of DMD (no sarcasm intended), but the release date listed for 2.062 is wrong. Probably because the site was generated from the master branch rather than the 2.062 branch (which has the correct date).
Re: D 2.062 release
On 2/17/2013 5:40 PM, Bill Baxter wrote: The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). I tried it on my ipod with Safari. Both changelog.html and bugzilla render fine, though it helps to turn the ipod sideways to get 'landscape' mode.
Re: D 2.062 release
On Sunday, February 17, 2013 23:08:41 Walter Bright wrote: On 2/17/2013 10:27 PM, Nick Sabalausky wrote: I'm happy that http://dlang.org/changelog.html; no longer shows a link for a yet-to-be-released version of DMD (no sarcasm intended), but the release date listed for 2.062 is wrong. Probably because the site was generated from the master branch rather than the 2.062 branch (which has the correct date). We should probably start generating the site from the latest released branch rather than master in order to avoid that sort of problem. - Jonathan M Davis
Re: D 2.062 release
On 2013-02-18 06:37, Steven Schveighoffer wrote: I agree, we need a better system. Manually edited has its faults, and the current system has its faults. We could have a section that is edited manually with some important highlights with proper full description of new features and deprecated/removed ones. Then, in addition to that we could have a link to bugzilla for the rest. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. -- /Jacob Carlborg
Re: D 2.062 release
On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting.
