I think I like Casey's recommendation here. Would you want to simply say that a release was cut, or actually list the changes under the release? We could probably do a couple things to that end.
1. Per Otto's comment, get the existing changelog in order - I think we should modify it to reflect a per-release formatting, which would mean grabbing historical changes to that file and enumerating them per release (or just having a very simple single change note). e.g., the 0.4.2 items get merged as follows (changing the date accordingly to reflect the release date) * Tue Sep 25 2017 Apache Metron <dev@metron.apache.org> - 0.4.2 - Add Alerts UI - Updated and renamed metron-rest script 2. Depending on how you guys feel about granularity, we could make changes in the current release added as a line-item under a CURRENT or 0.4.3-SNAPSHOT version, e.g. * RELEASE-DATE Apache Metron <dev@metron.apache.org> - CURRENT - METRON-1499 Enable Configuration of Unified Enrichment Topology via A - METRON-1483: Create a tool to monitor performance of the topologies c - METRON-1397 Support for JSON Path and complex documents in JSONMapPar - METRON-1460: Create a complementary non-split-join enrichment topology - METRON-1302: Split up Indexing Topology into batch and random access - METRON-1378: Create a summarizer Or have the release manager do it. The first route would leave a dev on the hook, but the release manager would then simply need to update the date and version info rather than collect all the changes. I'm unsure off the top of my head if rpm will blow a gasket over the date and version formatting, but we can find a way to make that work. The other approach would mean just doing a git log on the spec file and grabbing the delta since last release. Side note, I kind of like the idea of having the Jira ticket number in the comment like that in the second example. What do you guys think? Mike On Wed, Apr 18, 2018 at 9:23 AM, Otto Fowler <ottobackwa...@gmail.com> wrote: > I think having the spec file updated with the changes per release is fine, > but is the release manager > going to do that? > > If so then the docs need to be updated. Also, we *should* true up any > missing entries from the file now. > > > > On April 18, 2018 at 11:02:35, Casey Stella (ceste...@gmail.com) wrote: > > I think I'd prefer to see the changelog only include the release entries, > rather than individual entries per dev. We keep the spec file in source > control to determine the individual changes between releases. I'm happy to > have my mind changed, though. > > On Wed, Apr 18, 2018 at 9:47 AM Michael Miklavcic < > michael.miklav...@gmail.com> wrote: > > > We discovered yesterday while reviewing a PR that the RPM changelog > hasn't > > been maintained since 9/25/17. There are 7 changes to that file that have > > not been logged in the changelog itself. The question is if we want to > keep > > maintaining the changelog and, if so, should we patch the existing log > with > > the missing commits. Any opinions on this? I myself don't have a strong > > opinion either way, but we shouldn't leave it in its current state. > > > > Mike > > > > > > Quoting the conversation between myself and Justin Leet: > > > > https://github.com/apache/metron/pull/996#issuecomment-382194736 > > @justinleet Do we still want/need to do this? The last log change was Tue > > Sep 25 2017 by @merrimanr in METRON-1207. However, there have been 6 > > changes to the spec since then that have not made it to the change log. I > > believe there was a reason we started doing this (in duplication of > source > > control), but I don't recall specifically. Do remember why that was? > > > > https://github.com/apache/metron/pull/996#issuecomment-382199021 > > I believe, and my memory is pretty fuzzy, is that it's best practice to > > maintain that changelog because it's useful for auditing and tracking > > purposes given that it's available on the rpm itself. > > > > There's probably a couple questions here > > > > > > 1. Are we going to maintain it going forward? If not, we should just > > dump it entirely. > > 2. If we choose to do so, do we want/need to update the changelog for > > the missing commits (and probably to use the dev list as authors, rather > > than individuals)? > > > > > > Might be worth opening a discuss on it. I could be persuaded either way > in > > terms of whether we update it for this PR or not, but I have a slight > > preference on adding it until there's agreement we aren't doing it. > > >
