moved libraries

[superplay1]

why: cleaner structure
what: restructured model,chip,task
how: moved model.py one layer up, moved chip.py, tasks.py in libraries and modified imports

[CLAassistant]

All committers have signed the CLA.

[fedroy]

@superplay1 Please provide a regex replace command to update the script files.
@lazyoracle Is there a way to in some way "pin" these commands so that one is warned when running the code.
It would be optimal is when going from version X to version Y one is prompted with all the script modifications needed to make their scripts be compatible again. Does such a feature exist anywhere?

[lazyoracle]

@lazyoracle Is there a way to in some way "pin" these commands so that one is warned when running the code.
It would be optimal is when going from version X to version Y one is prompted with all the script modifications needed to make their scripts be compatible again. Does such a feature exist anywhere?

The standard practice is to use deprecation warnings and not make API breaking changes without a buffer release in between. For example, if we are now in 1.2.2 and thinking of making breaking changes, we should make a release 1.2.3 which includes deprecation warnings for all the parts of the codebase that we are planning to break, so that anybody using version 1.2.3 gets notified about where their scripts will break. This is typically also included in the CHANGELOG as discussed in #88. The breaking changes are then only made in 1.2.4 where as a best practice there should be error handling code that catches code which still tries to use the previous API and throws an error pointing them to the documentation of the updated API or instructions on how to upgrade their scripts.

[fedroy]

Should we use this PR as an example to implement the best practices you just described?

[picbeats]

The standard practice is to use deprecation warnings and not make API breaking changes without a buffer release in between.

Semver suggests that after a public API is released (Ver >= 1.x) API breaking changes should trigger major version increment. i.e. 1.2.2 -> 2.0.0-dev

[lazyoracle]

after a public API is released (Ver >= 1.x)

From what I understand, for all practical purposes our current 1.x release is more of a "private beta" and not a stable public API in the usual sense. As such API breaking changes should be fine until we move to a stage where we can call this stable and have a 2.0 release

[nwittler]

Looks good. Just provide the requested search replace expressions, e.g.
c3.system.model -> c3.model

[lazyoracle]

Everything looks good. Probably need to provide the search replace command as requested by @fedroy. You can just add it to the description of this PR.