updated release notes for 6.0 #380
Conversation
|
Did the release notes for 5.2 get moved into old release notes? |
|
Outside of Alec's comment, I think this looks fine. |
|
Evan points out that we may need some better process around this to deal with future changes to the 5.2 release notes. In the current approach, any changes to the 5.2 release notes in the 5.2 branch will result in merge conflicts when we try to bring it into master, so at least they shouldn't go unnoticed. I wonder if we moved the release notes on this branch to old-release-notes first and then created a new copy of the release notes, would git be smart enough to make sure changes to the 5.2 version go to the new location on master? |
|
Hm, that's a good question. I don't think git is particularly smart about file renaming. I did a local test that seemed to confirm this. (I wrote one file in branch 1, then in branch 2, I merged in branch 1, then renamed that file, made a commit, then created a new file with that same name. Then I went back to branch 1, edited the original file and committed, then I merged branch 1 into branch 2, and I got conflicts.) I'm not sure what the best way around this is. The bad case isn't actually merge conflicts, the bad case is something changes on release-5.2 that doesn't conflict, and then it winds up in the master release notes...for no reason. |
That would definitely be bad, but hopefully it's pretty unlikely. In the odd circumstance where it did happen, I guess we'd have to rely on the review to catch it in the current scheme. |
|
I think we'd also catch it when we looked at the release notes before releasing what's now on master. And if we actually did just publish the wrong release notes, we could just change them after the fact, and it's not that bad. |
|
(maybe this tool can be useful) |
|
I deferred the problem by removing the reference to old release notes |
updated release notes for 6.0
Also fixed versionstamp usage