<div dir="ltr"><div>I support anything that move us further away from the centralized/semi-manual way we make releases now and towards the perfect world that David Gobbi recommends. Automating releases further will cut down on the time it takes to put them together and make it feasible to do them very frequently and on a regular schedule.</div><div><br></div><div>Benefits of the current system are, besides the convenience for developers that David mentioned, are that the "tell us about your change?" emails are good karma and a nice way to reach out to new developers, and that from time to time the handcrafted release note announcements come out well. I for one am willing to trade these for multiple releases per year.</div><div><br></div><div>I vote for optional md file per commit in a directory for the time being. To get beyond that (which I think we should do) we'll have to enforce no merges without accompanying issues or something like that to train us all over to an ideal workflow.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>David E DeMarle<br>Kitware, Inc.<br>Principal Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-881-4909</div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Nov 7, 2017 at 2:54 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In a perfect world, the changelog would be generated automatically from all of the issues that were closed between releases.  That would require much more frequent use of the issue tracker (which would be a good thing).  Issues and MRs would continue to be tied together via gitlab references.<div><br></div><div>If someone wanted to see the latest changelog for master, they would just go to gitlab's list of closed issues.  The changelog put into the source upon release would just be an md file that was a copy of the same.</div><div><br></div><div>Overall, though, I'm not sure if a new changelog mechanism is even needed. The current workflow (summarizing our changes at release time) already seems pleasantly lightweight.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> - David</div></font></span></div>
<br>______________________________<wbr>_________________<br>
Powered by <a href="http://www.kitware.com" target="_blank" rel="noreferrer">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank" rel="noreferrer">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank" rel="noreferrer">http://markmail.org/search/?q=<wbr>vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank" rel="noreferrer">http://public.kitware.com/<wbr>mailman/listinfo/vtk-<wbr>developers</a><br>
<br>
<br></blockquote></div><br></div>