Hi, since "creating a release" could be also an JIRA issue, it would be good use such an issue and tell the auto-generated to start with this issue. I think usually the user of a new library is primary interested in the features (not in the x jira issues which happened before the first beta-release). Then after the first release the auto-generated will fulfill its work and show any modification.
Regards, Sven -----Original Message----- From: Ramesh Reddy [mailto:[email protected]] Sent: Freitag, 29. August 2014 20:07 To: [email protected] Subject: Re: [Discuss] Release notes of the Olingo OData Client for JavaScript Yi, One question I have is this for this one version where majority work done without JIRA or all the time going forward? In my experience a combination of 1 & 3 works very well for a open source project I work on. The JIRA would list comprehensive list of features, enhancements and bug fixes and manual page just to highlight major features. IMO for current release since it so new I would say use 3, as I suspect until it reaches a stable version most people not going to pay attention anyway. But start logging JIRAs for future. Ramesh.. ----- Original Message ----- > 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=12314520&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 >
