Release 0.9.0-rc2

[cholmes]

Fixed up changelog and updated version numbers

Related Issue(s): #
#718, #717, #714, #712, #710, #708,

Proposed Changes:

1. Update version numbers to 0.9.0-rc2
2. Added changelog info for asset description and data role, and moved paging changelog info from rc1 to rc2

PR Checklist:

• This PR has no breaking changes.
• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
• API only: I have run npm run generate-all to update the generated OpenAPI files.

[cholmes]

I'm not sure if I need to do more on the npm run generate-all. I just did a big find and replace on the 0.9.0-rc1 string. After I tried running the npm and git diff said no files changed, so I think this may be good?

[m-mohr]

We have a problem with the CHANGELOG here due to an unclear process. I thought the next version would be stable so I didn't add my PRs to the CHANGELOG as usually we merge the rc and the stable CHANGELOG and they are only fixing things that have been introduced with 0.9rc, so no changelog entry for 0.8 -> 0.9 required. We should clarify how we do RCs and CHANGELOGs. I always feel strange about merging the RC changelogs into stable as then you don't have changelogs between RCs and it leads to this confusion. Also, we would need to remove some of Alex changes when merging as they are not changes between 0.8 and 0.9. So we need to decide for one path and then update the changelog.

Options:

1. Keep CHANGELOGs for RCs and put all changes in the log
2. Don't do CHANGELOGs for RCs and don't add changes between RCs to the log
3. ...?

Also, there's #711 still open. Shouldn't we first fix all issues before doing a RC? Feels a bit rushed.

[cholmes]

I guess I naturally went to option 1) - it seems like there should be a way for people to track what happened between an RC1 and an RC2. Though most changes are minor it is possible a bigger change would occur, and we'd want an implementor to be able to easily see that it changed. And just feels better to track everything.

I think the one tweak I could see is when we make the release notes for 0.9.0 or any released candidate then we combine all the changes for the candidates. And when we blog it out we talk about all the changes. But it seems like the change log should track all the changes.

As for #711 - I missed that one. I had thought at the end of the last call we wanted to try to move ahead on an RC with what we had. I'm cool to wait, but we should try to get that fixed asap. I'm mostly keen to start on splitting the repos, but I suppose we also could branch 0.9.x if we do want it to bake for longer. That may also make a 0.9.1 release easier if we need it, since dev will start to change substantially.

[cholmes]

@matthewhanson - you need to approve this, since I made the original PR, even though you did the update.

But I think we should consider including #734 - or at least something that addresses the concerns raised, even if not that exact breakdown. We haven't pushed out 0.9.0, but it makes a bunch of substantial changes, based on assumptions about angles being different in aerial imagery, which they were not.

So let's decide on that one on monday and then try to release.