prefix with package name for foreign names

[KristofferC]

I was getting to know the code base but I found it quite difficult since I would look for a name and then found out it was defined in another package (like FEMBasis).

This PR adds prefixes to the names that are defined in other packages. It also updates with the changes + fixes in https://github.com/JuliaFEM/FEMQuad.jl/pull/15 (fixing names of HEX81 & co, and returning a length 1 tuple for 1 dim quadrature rules).

PR will fail until we either checkout the FEMQuad branch or tag it or something (one of the drawbacks with splitting things into multiple packages heh).

[TeroFrondelius]

I am ok with both options. There are unlimited version numbers available. Which ever is the most convenient way of working in this situation.

[ahojukka5]

Good changes. Now we explicitly define where are the types defined.

Now it would be a good place to make things right, not just almost right. From a practical point of view, should we now increase a patch or a minor version in FEMQuad and what would be best practice to work with this kind of multi-package environment to avoid dependency issues? Newest FEMQuad is now 0.2.0. Add minimum version requirement for FEMQuad to 0.2.1 for FEMBase?

[KristofferC]

I think what we can do is to have the packages use the master version of the dependencies, (FEMBasis, FEMQuad, FemBase) for a while and when we are ready to do release we tag all the packages.

[TeroFrondelius]

@KristofferC if the master version of the package depends on the master version of other packages, it won't break anything. We just need to remember to check dependencies before tagging new version. I really like this workflow for now. I believe it will solve the problem for now.

[KristofferC]

I might missunderstand you, but if a tag needs to be done for every change in a dependency then it is hard to do any experimental work since every new tag will be pushed to users.

I believe a release should be done when there is some confidence that the new stuff should be released to users but there also need to be a way to develop without tagging.

So for CI, using the master branch of FEMQuad here, until we want to make a release is what I propose.

[TeroFrondelius]

Yes, exactly. I liked what you proposed. Your proposal is perfect because it won't break anything. Afterward, when we will have new features, we will tag in the right order and fix the dependencies to be tagged versions again.

Yes please, change the REQUIRE file to depend on master (or any other way which works to depend on the master version).

[KristofferC]

I changed the .travis script so that we check out master of FEMQuad. Tests pass now.

[ahojukka5]

I lowered a coverage threshold to avoid failing coverage check because I think coveralls is not showing coverage right for Julia 1.0 syntax at the moment. Thus it doesn't make sense to require that every line is covered. And in general, to make development work smoother, we can tolerate 1-2 uncovered lines.