PR: Remove assert from code and refactor code a bit

[goanpeca]

Fixes #228

[dpizetta]

@goanpeca , thanks . I'd ask for two things:

• Require a merge with develop instead of master, as we are keeping the master identical to pypi.
• Could you also change the requirement pyflakes to "pyflakes<2.2.0,>=2.1.0" in the req-test.txt, so we get the CI working again;

Tks in advance

[dpizetta]

Oh, do not worry about the master/develop branch. You're right to merge to master, sorry.

[goanpeca]

@dpizetta how do the branches work at the moment?

[dpizetta]

@goanpeca the develop already has a new version for development, v2.9 for the new minor/major. We can use the master to patches, then we incorporate it into develop OR create a new branch from master (like 2.8.3) to add those patches (I think I did this in the last change). If you have better ideas fo how to keep them organized, let me know :) Tks

[goanpeca]

If you have better ideas fo how to keep them organized, let me know :) Tks

Hmm, that is a bit confusing , is that like a gitflow?

We could have a branch for the current stable version:

Option 1

2.x that means anything that will produce 2.8.2 and 2.9 and 2.10 etc...

And have master (or develop) be the next major release 3.x. That way current work that needs to go to the next minor or patch release will be done against 2.x and every PR merged is then "bubbled" up to master.

Active branches

• master -> 3.x work
• 2.x -> 2.x work

After a PR is merged to 2.x we can do:

A.)

git checkout 2.x
git pull upstream 2.x
git push origin 2.x
git checkout master
git merge 2.x
Commit message -> "Merge PR: XXX to master" 

This could be automated, unless there are conflicts in which case it will require manual intervention

B.) Periodically merge things from 2.x into master

git checkout 2.x
git pull upstream 2.x
git push origin 2.x
git checkout master
git merge 2.x
Commit message -> "Merge 2.x into master" 

This could be automated, unless there are conflicts in which case it will require manual intervention

Option 2

If we only plan to have a 2.x series and no work is planned to produce (for the time being) a 3.x version (like a major refactor or breaking change) then we could have just a master branch or a develop branch.

Active branches

• master -> 2.x work

[dpizetta]

Hi @goanpeca, something that for me is unlikely is that the master branch could not represent the pypi lastest version in those two models if I understand correctly.

I was using a simplified gitflow approach as we do not have so many branches nor fast changes or releases (daily, for example). That's why the develop branch starts a new minor version when merged into master. If an urgent/important bugfix is needed we can derivate a new branch from master for a hotfix, then master is merged it into develop, if we can hold until a new feature is introduced we can use the develop.

We can follow your first suggestion and keep the master sync with pypi changes, so using a develop, not master branch to be, for example, 3.x.

Thoughts?

[goanpeca]

I am fine with whatever we choose, but please document the current workflow (CONTRIBUTING.md) so that others (and me in this case :-p ) know what to expect, or against which branch PRs must be made.

I do not see the need for a branch to be exactly what is on PyPi since we have tags for that (which point to the exact commit that produced a version).