Updated text on dependency versions

brechmos-stsci commented 5 years ago

Had a long conversation with @eteq regarding "pinning" of dependencies and there were several assumptions and nuances that were discussed that I wanted to incorporate in the text. My take away was:

probably want to develop against current releases
setup.cfg / conda should be "pinned" only on minimal >= types of things
if / when things break due to a new release of somethign (e.g., glue-core) then we would have to go into the package (e.g., cubeviz) and do a quick point release to pin < new-breaking-release but really "this should never happen" as package developers should be deprecating rather than changing
as developers we do not need to be the ones that reproduce an environment, that is up to the user (e.g., if Jane Scientist uses cubeviz 0.2 to create some result and then wants to reproduce it 3 years later, then they have to track all the dependency versions, not us

Hopefully the text encompasses these thoughts.

SaOgaz commented 5 years ago

Adding note here after some in person discussion with @brechmos-stsci, sometimes we hit version limitations (caps on how high of a version we can access) in our astroconda channel because continuum hasn't updated to the latest version yet (i'm I remembering this right @jhunkeler?), so we will need to factor that in as well.

brechmos-stsci commented 5 years ago

bump @eteq @stscicrawford Is there anything else you would modified here, or is it good to merge now?

eteq commented 5 years ago

I think everything except the one bit above is all good. So if you are happy with my suggestion there I think it's good to go once implemented, @brechmos-stsci. So I'll approve this so as not to block merging if that change is made.

spacetelescope / style-guides

Updated text on dependency versions #79