chore: docs: Add Changelog and update docs sections on releasing and contributing (#79) (#94)

[rarruda]

About the changes

SSIA

Closes #79 && #94

Discussion points

1. Would like feedback from the Unleash team regarding the use of Changelog (see Release v4.0.0. What is the braking change? #79 ).

It is only useful if it is kept up-to-date, so it does require a bit more effort in documenting changes. Not sure what is the practice in the other SDKs, or if you guys have opinions regarding this. (maybe referring to the gitlog is a good enough policy?)

Only went back to release 4.0.0 when recreating the changelog history.

2. Also thought it would be nice to clarify the steps when creating a new release.

Thought it would be nice to have these in place before creating the next release. 🙂

[coveralls]

Pull Request Test Coverage Report for Build 5268590795

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+96.9%) to 96.876%

---

Totals
Change from base Build 5052083046:	96.9%
Covered Lines:	2419
Relevant Lines:	2497

---

💛 - Coveralls

[thomasheartman]

I think this looks great! And big kudos for documenting all changes back to v4 🏆

Regarding your questions:

1. I think having a curated changelog is super useful. Yes, it requires some more work, but I think it's worthwhile. I don't think we have a standard for this anywhere. The closest is Unleash proper, which is moving away from a git log-generated changelog to a manually created one (similar to what you've done here 🙌🏼 ).
2. Steps on how to create a release are also very much appreciated! Super helpful!

So in other words: I'm very on board with this. It may be that the others have some thoughts on changelogs in other SDKs, though, so we could wait and see what they say 💁🏼

[rarruda]

Let's wait for another day then.

I see that the python SDK has also a changelog but follows a different standard. Not sure if standardizing is as important as having it (or not). 🤷

[sighphyre]

Basically what Thomas says - each SDK has it's own patterns around this (honestly it's own patterns around everything) I don't think they need to remain in lockstep. But I support having a changelog, it's definitely nice for users to be able to find this information without asking so LGTM!

[sighphyre]

LGTM!

[thomasheartman]

@rarruda Is there anything left to do before merging this? It's been siting around for a bit, so just wanted to check in ☺️

[rarruda]

There are a couple of changes missing links to their PRs and at least one typo still. Also I've had very little free time lately.

I will try to get this one out very soon so we can have the next release including pr #145 already here.

[thomasheartman]

Understood! Would you be willing to merge it now and update the remaining links and typos later or would you rather wait to get it fixed? And I'd be happy to put in a description of #145 under either a new 4.4.3 header or the unreleased header. Got any preferences?

[rarruda]

Feel free to add to the 4.4.3 header since that's coming right around the corner! :)

[thomasheartman]

Wait, sorry, I'm afraid I've made a mess. It says 4.4.3 was released on May 23, but I don't see that release on rubygems? I added the new stuff under 4.4.4 because 4.4.3 already existed. What's the right course of action here?

[thomasheartman]

Update: I've gone ahead and done what I suggested. Looks like 4.4.3 was never released, so I've added it there.