Set compatibility bounds

[CiaranOMara]

No description provided.

[tlnagy]

What's the rational for removing the upper bound?

[CiaranOMara]

There is a good track record for many of the packages used here. Take DataStructures for example. This PR moves the upper bound to the next major release and thus treats the packages as having reached their first major release. Maybe it is better to continue to handle versions with a major version of 0 as incompatible with each other (Caret-specifiers). I wasn’t sure what people would think about this PR.

I also suggested a similar version bound for Cairo.jl (#366 and GiovineItalia/Gadfly.jl#1340), which may need to be altered as of an outcome of the decision made here.

[CiaranOMara]

Having thought about this a moment more, I think we should follow the semantic versioning as modified by Pkg.jl. However, I would suggest the adoption of the GitFlow workflow so that trivial fixes or compatibility increments are not blocked by development.

[bjarthur]

according to your link to Pkg: "Caret specifiers are the default and hence 1.2.3 == ^1.2.3". so i believe what this PR does then is to remove compatibility for, e.g., DataStructures >0.12. am i mistaken here?

either way, the choice of removing the upper bound depends on how reliable you want your code to be in the future. were it used in an airplane, i'd say definitely don't automatically assume future versions of your dependency will work.

[CiaranOMara]

@bjarthur, you are correct, this PR would remove compatibility, which was not intended.

My mistake was momentarily thinking major releases of 0 would behave like other major releases.

For others looking on, since caret specifier is the default, something like EzXML = "0.8, 0.9" would become EzXML = "^0.8, ^0.9", which because major versions of 0 are additionally incompatible with other major versions of 0, would then equate to the union of [0.8.0, 0.9.0) and [0.9.0, 0.10.0).