Re: (Fwd) Preparing for 1.7 release

I think you have missed the point of the release notes. It is supposed  
to summarize in easily accessible form, the information that a user  
needs to know about the consequences of upgrading to a new release. To  
that extent, it should present categories of changes to various  
components. The change log (which is what you can get from subversion)  
has a completely different purpose - to describe the reasons for a  
sequence of commits. I do not believe that it is even theoretically  
possible to transform one into the other. That is why release  
announcements often include both.

If you look at the older release notes, you will examples of this (the  
notes for 1.3.0 are here as an example). Note the identification of  
areas in which problems were fixed and enhancements were made. Others  
include notes to users about adjustments they need to make. I do like  
your use of links to bug reports; however, not every problem has been  
formally reported as a bug, patch, or enhancement. I would really hate  
to lose this kind of structure:


28-Nov-2001 1.3.0
Acknowledgements:
     Thanks to Oliver Imbusch for finding and fixing problems with  
parsing of encoded link parameter names and values and
         of link URLs with parameters and fragments.
     Thanks to Paul Frantz and Dave Glowacki for finding and fixing  
problems with parsing of link parameter names without values.
     Thanks to Didier Besset for new WebForm methods:  
hasParameterNamed and hasParameterStartingWithPrefix
     Thanks to Peter RoÔøΩbach for catching some typos in the  
tutorial.
     Thanks to Benoit Xhenseval for adding a mechanism to handle HTML  
parser errors.
     Thanks to Benoit Xhenseval for optimizing the use of DOMs and  
StringBuffers.
     Thanks to Bradley Smith for implementing getParameterNames in  
ServletUnit.

Problems fixed:
     1. Links with parameters whose names were encoded were being mis- 
parsed
     2. Links with empty parameter values were being mis-parsed
     3. Most references to TestCase.assert have been renamed to  
assertTrue in order to prepare for JDK 1.4 and JUnit 3.7
        compatibility. HttpUnitTest and ServletUnitTest implement  
assertTrue to continue support for JUnit 3.6 and earlier.
     4. ServletUnit was not decoding its request parameters and names
     5. ServletUnit's HttpRequest.getParameterNames method was not  
implemented
     7. WebSphere cookie values ending with "=" or "==" are now handled.
     8. HttpUnit should now be more tolerant of missing character  
encodings

Additions:
   Content and parsing enhancements
       1. It is now possible to check a WebForm for the presence of a  
named parameter.
       2. Disabled submit buttons may no longer be selected from a form
       3. When enabled, parameter validation now prevents changes to  
readonly controls.
       4. It is now possible to obtain the reason message associated  
with the status code, either from
          HttpException.getResponseMessageweb() or if exceptions are  
disabled, from WebResponse.getResponseMessage()
       5. HttpUnitOptions now has methods addHtmlErrorListener and  
removeHtmlErrorListener. If a listener is registered,
          it will be invoked for every error or warning generated by  
the parser, indicating the URL, line and column number
          of the error and a textual description of the problem.

   ServletUnit enhancements
       6. ServletUnit now compiles against Servlet 2.3
       7. ServletUnit now handles web.xml partially, supporting:
          a. mapping of exact paths to a servlet class
          b. protected URLs (exact paths only)
          c. Basic and Form authentication
          d. Servlet initialization parameters

    Documentation and Packaging
       8. There is now the beginnings of a tutorial, focused on  
ServletUnit but covering much of the HttpUnit API
          in doc/tutorial
       9. Archives are now rooted with the build name, following unix  
conventions

    Optimizations
      10. HttpUnit now pre-allocates StringBuffer instances to their  
most likely size
      11. DOMs are no longer copied when passed internally'
      12. ByteTag objects no longer allocate Hashtable unless required


On Apr 19, 2008, at 6:10 AM, Wolfgang Fahl wrote:

> Dear httpunit developers,
>
> Russell wrote:
> >The final step in preparing for an HttpUnit release has always  
> been  cleaning up the release notes. My practice >has been to update  
> them  with each change, indicating >what (from a user's perspective)  
> has
> >changed, and referencing any patches, bugs, or >enhancement  
> requests  that are relevant. The cleanup >step, then, simply  
> involved reordering
> >and reformatting the notes. The release notes at >present,  
> however,  have a change log in them, which I >find confusing and not  
> very helpful
> >at all. If you know or can figure out from the log what >has  
> actually  changed in HttpUnit's behavior, can you >convert the  
> change log to  release notes, in keeping >with previous releases?
> There is now a korn shell script svnlog2releasenotes.ksh
> which I checked into the trunk revision.
>
> It extracts the information from the svnlog selects patterns of  
> changes that should be ignored and looks for patch and bug report  
> numbers as well as the revision.
>
> The result is than output as a html code for a list that has links  
> to the patches and svn revisions. I've renamed the release notes  
> from txt to html, put the old stuff in
> <pre></pre> and added the new list.
>
> If we combine our approaches we'll be able to have release notes as  
> in the past  - please let me know how a proper svn comment should  
> look like to fit to the release notes format your are expecting and  
> I'll see to use such a format for all future svn commits. If some of  
> the current entries still need fixing (e.g. if a link is broken  
> since it points to a bug instead of a patch or vice versa) we may  
> fix this step by step on the feedback from people stumbling over  
> such a problem (or somebody could use the checking broken links  
> problem as a good tutorial step for httpunit self)
>
> Yours
>   Wolfgang
>
> BITPlan - smart solutions
> Pater-Delp-Str. 1, D-47877 Willich Schiefbahn
> Tel. +49 1805 - BITPLAN / +49 1805 248 752, Fax +49 2154 811-481
> Web: http://www.bitplan.de
> bitplan GmbH, Willich - HRB 6820 Krefeld, VAT-ID: 10258040548,  
> Geschäftsführer: Wolfgang Fahl
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
> Httpunit-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/httpunit-develop

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Httpunit-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/httpunit-develop