+1 for updating CHANGES.txt on all versions. I think there'll still be some confusion when a new version (0.9 for example) becomes active though.
We also need to update the Affects version and Fix version correctly. On Thu, Aug 13, 2015 at 1:13 PM, Hitesh Shah <hit...@apache.org> wrote: > CHANGES.txt via git commit log would be quite useful. Incorrect commit > messages cannot be fixed in git though so there may need to be some manual > edits needed from time to time. > > In the meantime, should we just make a call to update each section in > CHANGES.txt based on where a particular fix went in? i.e. if commit is > going to branch-0.6, it should go into the sections for all unreleased > versions for master, branch-0.7 and branch-0.6? > > Likewise to answer @Rajesh’s question, I think the Incompatible changes > section should likely be treated as a subset of the All Changes section. > > Comments? > > — Hitesh > > On Aug 6, 2015, at 12:54 PM, Siddharth Seth <ss...@apache.org> wrote: > > > It does get fairly confusing on where a patch goes in with the multiple > > releases which are in progress right now. > > Putting an entry in the earliest version isn't very useful either - since > > it's tough to figure out order of releases. Fixed in 0.5.4, but was it in > > 0.6.2 would depend on whether 0.6.2 was released after. > > Also we often end up back-porting patches at a later point, at which > point > > - there's multiple entries. However, they're not necessarily in all > > sections. > > > > Using the commit log may be a good option. We'll have to be careful about > > commit messages getting the jira number correct, and potentially have a > > pattern for addendum patches and corrections, so that a script can easily > > parse this. > > Figuring out incompatible changes isn't easy from this - without querying > > jira in parallel. > > > > The fix version in jira - if set to all versions where a patch goes in - > > would work well also. There can be a single jira query to check for > > versions, title, incompatible and potentially release notes - if > something > > specific needs to be called out for a fix. > > > > Setting affects version to all relevant versions helps as well - for > users > > to lookup whether a bug exists in a specific version, and when it was > > fixed. This would likely need to be set to the min version within a > release > > line where it exists. The diff between that and the fix version should > give > > an idea of the range of releases where a bug exists. > > > > - Sid > > > > On Wed, Aug 5, 2015 at 4:01 PM, Rajesh Balamohan <rbalamo...@apache.org> > > wrote: > > > >> Also, What should be followed for incompatible changes? > >> - Should we treat "INCOMPATBILE CHANGES" as a subset of "ALL > CHANGES"? > >> Currently, we add it only in "INCOMPATBILE CHANGES" section. > >> - Let us say we have "TEZ-1111" to be added in "INCOMPATBILE CHANGES" > >> in 0.5.x branch. Should we add it to "INCOMPATBILE CHANGES" in other > >> branches as well (0.6, 0.7, master)? > >> > >> ~Rajesh.B > >> > >> On Thu, Aug 6, 2015 at 4:01 AM, Hitesh Shah <hit...@apache.org> wrote: > >> > >>> Given that we have parallel branches going with their own different > >>> timelines on when a maintenance/patch release is done, what does folks > >>> think about the way we are currently tracking what changes went into > each > >>> and every particular branch/release? > >>> > >>> For example, a commit for say TEZ-11111 would have been committed to > >>> master, branch 0.7, branch 0.6 and branch 0.5. Putting the entry for > >>> TEZ-11111 into only one section in CHANGES.txt makes it confusing to > >> figure > >>> out which release the fix is available in. > >>> > >>> There are multiple options we could take: > >>> 1) Create a CHANGES.txt/release notes from the git commit log for a > >>> given branch. > >>> 2) Add an entry into every release section in CHANGES.txt i.e. 4 > >>> entries for TEZ-11111 in master CHANGES.txt and corresponding one into > >> the > >>> relevant CHANGES.txt for each branch > >>> > >>> The above are not completely useful to the user unless JIRA is kept in > >>> sync and up to date to match the branches in which the fix was > committed. > >>> Likewise for setting “Affect Versions” correctly. > >>> > >>> Any other options/ideas? > >>> > >>> thanks > >>> — Hitesh > >> > >
