Closed Bug 713346 Opened 13 years ago Closed 13 years ago

Release notes for Bugzilla 4.2rc1

Categories

(Bugzilla :: Documentation, defect)

4.1.3
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Bugzilla 4.2

People

(Reporter: LpSolit, Assigned: LpSolit)

References

Details

Attachments

(1 file, 4 obsolete files)

No description provided.
Flags: blocking4.2+
Attached patch WIP, v0.1 (obsolete) (deleted) — Splinter Review
I have 3 sections left to write, and I will be done with it. I have split the release notes for Bugzilla 3.x and 4.x. release-notes.html.tmpl contains relnotes for 4.x while release-notes3.html.tmpl contains relnotes for 3.x.
Attached patch WIP, v0.2 (obsolete) (deleted) — Splinter Review
I still have to write the Outstanding Issues and Code Changes Which May Affect Customizations and Extensions sections.
Attachment #584195 - Attachment is obsolete: true
Attached patch relnotes for 4.2, v1 (obsolete) (deleted) — Splinter Review
Full relnotes for 4.2.
Attachment #584343 - Attachment is obsolete: true
Attachment #584352 - Flags: review?(dkl)
+ these queries should return more accurate results, + i.e. based on a more intuitive logic. I don't know if previously, results were not accurate. ==> maybe transfer this into: + The results of these queries will be more according expectations, as they are built by using a more intuitive logic.
(In reply to bigstijn from comment #4) > ==> maybe transfer this into: > + The results of these queries will be more according expectations, as they > are built by using a more intuitive logic. Ah yes, thank you! I didn't know how to phrase this correctly. :)
Attachment #584352 - Flags: review?(mkanat)
Comment on attachment 584352 [details] [diff] [review] relnotes for 4.2, v1 >=== modified file 'template/en/default/pages/release-notes.html.tmpl' >+The main change is about >+ the rewrite of the search system, which should now behave in a more intuitive >+ way, especially for complex queries. Both the backend and front UI code have >+ been improved for a better user experience. This new release also includes >+ support for SQLite, which becomes the fourth supported database server with >+ MySQL, PostgreSQL and Oracle. Numerous improvements to our WebServices API >+ have also been made.</p> Replace with: This release contains major improvements to search, support for SQLite, improved WebServices, and lots of other enhancements. >+[% INCLUDE db_req db='mysql' db_new => 1 dbd_new => 1 %] >+ >+[% INCLUDE db_req db='pg' db_new => 1 %] Is that accurate? >+<h3 id="v42_feat_sqlite">SQLite Support</h3> Title as "Experimental SQLite Support" >+<p>SQLite is now supported by [% terms.Bugzilla %] and becomes the 4th supported >+ database besides MySQL, PostgreSQL and Oracle. SQLite support must be considered >+ as experimental, at least till the next major release.</p> Add a second paragraph: <p>Note that use of SQLite is only recommended for small installations. Larger installations should use MySQL, PostgreSQL, or Oracle. >+<p>When you want to copy some text and upload it as an attachment, you no longer >+ need to first save your text into a local file on your machine and then upload >+ this file to [% terms.abug %]. You can now paste this text into a text field >+ directly, and it will be converted into an attachment for you. You can still >+ upload text and binary files as usual, of course.</p> Replace with: <p>You can now create a new attachment simply by pasting some text into a text field, in addition to the normal upload process for attachments.</p> >+<h3 id="v42_feat_email">Email Notifications now Available in HTML Format</h3> Replace with: "HTML Bugmail" >+<p>A new <em>Preferred email format</em> user preference has been added which lets >+ users decide the format in which they want to get [% terms.bug %]mails. Besides >+ the old text-only format, it's now possible to get email notifications in HTML >+ format.</p> Replace with: By default, bugmails (email notifications about changes to bugs) are now sent in an HTML format that is more readable than the old text format. Those who prefer the old text format can still choose it in their <a href="userprefs.cgi">General Preferences</a>, however. >+<h3 id="v42_feat_search">Improved Searching System</h3> >+ >+<p>The searching system has been heavily modified to be more flexible and to work >+ in a more sensible way. Complex queries are easier to build thanks to a slightly >+ improved User Interface, and these queries should return more accurate results, >+ i.e. based on a more intuitive logic. Some very complicated queries are still >+ impossible to generate from this new UI, though. Things should improve in future >+ releases.</p> This should talk only about Custom Search instead of talking about the whole search system. It's true that the backend was fully redesigned, but the thing that users will see is that Custom Search is different. >+<h3 id="v42_feat_buglist">New Default Columns List for [% terms.Bug %]lists</h3> This is a minor feature and should go into the Other Enhancements list. >+<h3 id="v42_feat_secure">Cryptographically Secure Pseudorandom Number Generator >+ Rewritten</h3> This is a minor feature that users don't generally care about and should go into the Other Enhancements list. It can go near the top of the Administrators list, though--it's definitely something admins who have to install Bugzilla will be happy about. :-) >+<h3 id="v42_feat_audit">Auditing of All Changes Within [% terms.Bugzilla %]</h3> >+ >+<p>[% terms.Bugzilla %] now logs all changes made via the <kbd>Bugzilla::Object</kbd> >+ module, That won't mean anything to most Bugzilla administrators. Instead, we should say something like: "Most changes made through the admin interface are now logged to the database, in the <kbd>audit_log</kbd> table." >+<h3 id="v42_feat_wai">Make [% terms.Bugzilla %] Compliant with the W3C Web >+ Accessibility Initiative (WAI)</h3> Let's just call this "Accessibility". >+<p>Progress has been made to make [% terms.Bugzilla %] compliant with the W3C WAI. Replace with: A project has started to make Bugzilla compliant with the W3C Web Accessibility Initiative standards. >+ restarting the web browser) displays the right page. This feature is only >+ supported by browsers which support <kbd>history.replaceState</kbd>.</li> Let's be more explicit about specifically which browsers support that right now. (In particular, that IE 9 does not support it.) >+ <li><strong>Searches:</strong> Personal tags can be used as a criteria for >+ queries. Listing them in [% terms.bug %]lists will be implemented in a future >+ release.</li> This isn't that helpful to the user. If we are even going to list this in the Release Notes, we should be more explicit about what a user could specifically do to use this feature. >+ <li><kbd>X-Frame-Options = SAMEORIGIN</kbd> is now passed to all page headers >+ (except when viewing attachments, as they can be on a different host) to >+ protect users from framing and subsequent possible clickjacking problems.</li> Hmmm, maybe this should go into the Administrators section? >+ <li><strong>Database:</strong> MySQL 5.0.15 and DBD::mysql 4.001 or newer are >+ now required. This permitted to rewrite some parts of <kbd>checksetup.pl</kbd> >+ to make it faster with MySQL.</li> >+ <li><strong>Database:</strong> PostgreSQL 8.0.3 or newer is required.</li> These are covered by the Required Modules section and don't need to be listed here. >+ <li><strong>Configuration:</strong> A new parameter <em>default_search_limit</em> >+ has been added (default: 500) which limits the number of [% terms.bugs %] >+ displayed by default in a [% terms.bug%]list. The user can ask to see a larger >+ list, though.</li> This should also be noted in the Users section, that by default queries will only return 500 results and they can click to see more. >+ <li><strong>Products:</strong> Older versions, milestones and components can now >+ be disabled. [% terms.Bugs %] already using them are not affected, but these >+ values are not available for new [% terms.bugs %].</li> This should be listed as a major feature. >+ <li><strong>Custom Fields:</strong> A custom field can now be displayed based >+ on multiple values of another field. Previously, you could only display >+ a custom field based on a single value of another field.</li> Major feature. >+<h3>IMPORTANT: Apache Configuration Change</h3> > [snip] This was in the 4.0 release notes and doesn't need to be repeated here. >+<h4>mod_perl</h4> > [snip] And same for this.
Attachment #584352 - Flags: review?(mkanat) → review-
Attached patch relnotes for 4.2, v2 (obsolete) (deleted) — Splinter Review
I fixed everything you said. Thanks for your initial review. :)
Attachment #584352 - Attachment is obsolete: true
Attachment #584352 - Flags: review?(dkl)
Attachment #584517 - Flags: review?(mkanat)
Attached patch relnotes for 4.2, v2.1 (deleted) — Splinter Review
I added bug 706753 to the Outstanding Issues section, to mention that Bugzilla won't work with the 1.x series of JSON::RPC.
Attachment #584517 - Attachment is obsolete: true
Attachment #584517 - Flags: review?(mkanat)
Attachment #584561 - Flags: review?(mkanat)
Attachment #584561 - Flags: review?(dkl)
Comment on attachment 584561 [details] [diff] [review] relnotes for 4.2, v2.1 Review of attachment 584561 [details] [diff] [review]: ----------------------------------------------------------------- Thank you so, so much for doing this. :-) ::: template/en/default/pages/release-notes.html.tmpl @@ +158,5 @@ > +<h3 id="v42_feat_search">Improved Searching System</h3> > + > +<p>The Custom Search section in the Advanced Search page has been redesigned > + to work in a more sensible way. Complex queries are easier to build and the > + results of these queries will be more according expectations, as they are built This is good. :-) Slight fix: Complex queries are easier to build and have more sensible results, as they are built using a more intuitive logic. @@ +171,5 @@ > + > +<h3 id="v42_feat_custom">Displaying a Custom Field Value Based on Multiple Values > + of Another Field</h3> > + > +<p>A custom field can now be displayed based on multiple values of another field. Add after this: (For example, one custom field could now appear in multiple products.) @@ +1312,5 @@ > > +<h2 id="v40_previous">Release Notes For Previous Versions</h2> > + > +<p>Release notes for versions of [% terms.Bugzilla %] of the 3.x series are > + available <a href="page.cgi?id=release-notes3.html">here</a>.</p> I would replace this paragraph with: <p><a href="page.cgi?release-notes3.html">Release Notes for Bugzilla 3.x and Earlier</a></p>
Attachment #584561 - Flags: review?(mkanat) → review+
Attachment #584561 - Flags: review?(dkl)
Flags: approval4.2+
Flags: approval+
Comment on attachment 584561 [details] [diff] [review] relnotes for 4.2, v2.1 Review of attachment 584561 [details] [diff] [review]: ----------------------------------------------------------------- Rest looks good to me. r=dkl ::: template/en/default/pages/release-notes.html.tmpl @@ +284,5 @@ > + <li><strong>Configuration:</strong> A new parameter <em>max_search_results</em> > + has been added (default: 10000) which limits the number of [% terms.bugs %] > + a user can request at once in a [% terms.bug%]list. This is a hard limit and > + a user cannot bypass this value.</li> > + <li><strong>Configuration:</strong> A new parameter <em>user_autocompletion</em> A new parameter <em>ajax_user_autocompletion</em>
I fixed all your comments on checkin. Thanks for the review. :) Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/ modified template/en/default/pages/release-notes.html.tmpl added template/en/default/pages/release-notes3.html.tmpl Committed revision 8052. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.2/ modified template/en/default/pages/release-notes.html.tmpl added template/en/default/pages/release-notes3.html.tmpl Committed revision 7988.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: