[FEATURE] add proper versioning and change logging

[jpdeleon]

We should add proper pip versioning and change logging (e.g. pip change log).

Also, use

pip install fastquant --upgrade

in doc and jupyter notebooks to make sure to use the most updated version.

[enzoampil]

Relevant resources

https://semver.org/ https://keepachangelog.com/en/1.0.0/ we've been using release-drafter in asimov: https://github.com/release-drafter/release-drafter

[jbdelmundo]

Suggestion to add contrib directory for initial contributions (strategies, indicators, data, anything applicable) then moving to the main functionality once stable and tested.

[enzoampil]

hmmm @jbdelmundo can you clarify on this? Do you mean to have a copy of each module for "new" contributions, after which we move to the main?

Just wondering how this differs from having a separate branch? My view is if we want to have a version of fastquant, that has less tested and (potentially) less stable versions, these should be kept in a separate, say develop, branch rather than a directory -- expect this to be cleaner. Glad to hear thoughts :smile:

[jbdelmundo]

I agree @enzoampil . I think a develop and a release branch would be better instead of having a separate directory.

The develop branch would receive PR contributions. This branch is expected to be rapidly changing as PRs are merged into this branch.

To better manage versions, we can have a release branch where a group of changes from the develop will be updated as a new "version" of fastquant

To illustrate, there will be 4 PRs :

1. A release version branch is from develop with the latest PR

   develop    |   release
   PR 1        |   PR 1

2. PR 2, PR 3 and PR 4 are merged into the develop branch, the release branch remains unchanged

   develop    |   release
   PR 2        |   PR 1
   PR 3        |   PR 1
   PR 4        |   PR 1

3. A new release version is made when changes from develop are merged and the changes from PR 2, PR 3 and PR 4 are "released"

   develop    |   release
   PR 4        |   PR 4

[enzoampil]

I think above is great for a lot of production environments. However, I'm realizing now that it might be overly complex for the current stage of fastquant. I'll revisit this at a later stage.

I think changelog announcements can be done whenever we decide to update fastquant on pypi since this is the closest we have to an actual release. This will be the first iteration of performing changelogs, and proper announcements on the same.