[ckan-dev] CHANGELOG for CKAN 2.0

[Sean Hammond]

> I think we should start doing it in the pull requests. I don't know if you
> agree, but I guess writing it a few months after the code was written,
> whenever we do the release, is too much work (and error prone).

Yeah it sucks. Writing the changelog as we go would be better if we
could do it, yes. If we do have to write the whole changelog at release
time then having smaller more frequent releases would make it easier.

> I think this is mainly because we a) work on branches inside the main repo,
> and; b) consider branches in the main repo to be public, so don't
> amend/rebase/change commits. To solve this, IMO, we need to change either
> a) or b).

I think once a commit has been pushed to any repo on github (including
your own fork!) then it's public and shouldn't be changed, e.g. should
not be deleted or amended. You can rebase but as I understand it you
should do the rebase on a new branch and pull request. But I'm not sure
what the best practices are here as we've never really done rebasing in
CKAN.

> This is a good point, to give a summary of the discussions that led to
> the commit.
> 
> But I guess we're OK relying on GitHub issues as well. If they ever
> get out of business (or we move to a new tool), we'll probably not
> only import the code, but also their issues and pr, to our new home.

I'm not so sure about that (we haven't imported trac tickets into github
issues, for example).