Ajay, I have made 3 releases on Apache Falcon and one in Apache Atlas and I beg to differ from your opinion.
Pointing users to use Jira or Git for looking at release notes is bad and it immensely helps users to just glance at the text file to parse what has gone into trunk. On Wed, Jan 20, 2016 at 11:38 AM Ajay Yadav <[email protected]> wrote: > Just to clarify I am not suggesting to not provide change log to users. I > am just suggesting to get rid of the practice of manually maintaining > CHANGES.txt file in the code. > > For example we can generate change log from JIRA(it provides release notes > for a particular release) and put it on website along with release notes. > We can also consider the Hadoop method if it doesn't involve extra manual > work for committers along with each commit. > > > Cheers > Ajay Yadava > > On Thu, Jan 21, 2016 at 12:58 AM, Ajay Yadav <[email protected]> > wrote: > > > As I said Idea is to delete CHANGES.txt as the same information can be > > extracted from JIRA. We can provide change log information using JIRA. > > > > Maintaining CHANGES.txt file is a huge pain for the people who have to > > commit patches. It is also very error prone way of maintaining change > log. > > We have a 6 weekly release cycle so that means that we are almost always > > running in two branches and it becomes very painful to maintain the > change > > log in this fashion. > > > > > > > > Cheers > > Ajay Yadava > > > > On Thu, Jan 21, 2016 at 12:38 AM, Suresh Srinivas < > [email protected]> > > wrote: > > > >> Hadoop has a script to generate CHANGES.txt. That might be an option. > >> > >> Agree with Venkatesh. This is an important information and should not be > >> deleted. > >> > >> On 1/20/16, 10:55 AM, "Seetharam Venkatesh" <[email protected]> > >> wrote: > >> > >> >I think this is quite useful and AFAICT, the release timelines are > >> >quarterly, it might be worth the extra effort to maintain this. > >> > > >> >-1 from me. > >> > > >> >On Wed, Jan 20, 2016 at 10:52 AM Ajay Yadava <[email protected]> > >> >wrote: > >> > > >> >> Currently we are maintaining CHANGES.txt to record contributions, > >> >> committers of the commits and the release in which they got > committed. > >> >>All > >> >> this information is also available in JIRA and git. > >> >> > >> >> However, there are certain disadvantages of CHANGES.txt, every time > >> >>during > >> >> release we have to maintain different CHANGES.txt in master and > branch. > >> >>We > >> >> have to be careful with subtle details like "Proposed release > version" > >> >>and > >> >> "Released version" etc. This also creates confusion when same commit > >> >>gets > >> >> committed into master and the branch. > >> >> > >> >> Also, it entails committers to do some edits to the patch submitted > by > >> >>the > >> >> contributor. This is error prone and can be tedious sometimes. > >> >>Sometimes we > >> >> forget to attribute contribution or spell contributor's name > >> >>incorrectly. > >> >> > >> >> Hence I propose to delete CHANGES.txt from master (0.10 onward). > Please > >> >> provide your inputs. If everyone agrees, then I will create a JIRA > and > >> >> delete CHANGES.txt from master. > >> >> > >> >> > >> >> Cheers > >> >> Ajay Yadava > >> >> > >> > >> > > > > -- > _____________________________________________________________ > The information contained in this communication is intended solely for the > use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally privileged > information. If you are not the intended recipient you are hereby notified > that any disclosure, copying, distribution or taking any action in reliance > on the contents of this information is strictly prohibited and may be > unlawful. If you have received this communication in error, please notify > us immediately by responding to this email and then delete it from your > system. The firm is neither liable for the proper and complete transmission > of the information contained in this communication nor for any delay in its > receipt. >
