Hi together, I suggest and prefer a mixture of method 1. and 2. For the most noteworthy and major issues create a according JIRA issue and all other (minor) issues can be put together in one comprehensive JIRA issues. This should be a good compromise between mention all noteworthy changes and do not have to create a lot of (probably small) JIRA issues. And afterwards the auto-generated release notes can be used.
Kind regards, Michael On 29.08.14 10:54, "Yi Ding" <[email protected]> wrote: >Dear Olingo developers, > >This is to discuss about the release notes of the Olingo OData Client for >JavaScript. We'd like to seek your advice on its content and location. > >On http://olingo.apache.org currently, the release >notes<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=123 >14520&version=12327170> is on the download >page<http://olingo.apache.org/download.html> of the library and its >content is auto-generated by the related JIRA issues. Our current problem >for following this practice is that, at the early stage of the >development of this first V4 version, we haven't been using JIRA to track >work items. And we finished 80% the work of porting from V3 to V4 before >we first pushed to the Olingo Git repository. Now it's hard for us to >auto-generate release notes using the JIRA issues or commit descriptions >that reflect all what we've done for this first version. To resolve this >problem, we came up with the following possible mitigations: > >1. Open a few new issues that reflect the work that hasn't been >tracked formerly. Then auto-generate the release notes. > >2. Open a comprehensive issue in which the release notes manually >written by us are included in the Description area. Then auto-generate >the release notes containing this one issue and a few others we created >during the later period of development. > >3. We don't use the auto-generated page. Instead, we use a page >that only contains manually written release notes. > >It would be nice if you could advice the best out of the three and >propose other better method if any. If you have any questions, we shall >be happy to answer. > >Best, >Yi
smime.p7s
Description: S/MIME cryptographic signature
