Challenge 1 — Solution

Task: For each of these version constraints, write out in your own
words exactly which versions would be considered acceptable: ^1.2.0,
~1.2.0, 1.2.*. Then explain which one you'd choose for a new project
dependency, and why.

^1.2.0
  Accepts 1.2.0 and any later version up to (but not including) 2.0.0
  - so 1.2.1, 1.3.0, and 1.9.9 would all be acceptable, but 2.0.0 would
  not. This trusts SemVer's promise that only a MAJOR version bump
  (the leading "1") is allowed to introduce breaking changes.

~1.2.0
  Accepts 1.2.0 and any later PATCH version, but stops before the next
  MINOR version - so 1.2.1 and 1.2.9 are acceptable, but 1.3.0 is not.
  This is more restrictive than ^1.2.0, since it blocks new features
  (MINOR bumps) as well as breaking changes.

1.2.*
  Accepts any version starting with "1.2." - functionally almost
  identical to ~1.2.0 for this specific case, matching 1.2.0, 1.2.1,
  1.2.9, etc., but not 1.3.0.

Which one to choose for a new project dependency:

^1.2.0 is the better default choice for most new project dependencies.
It strikes the right balance: it lets genuinely useful updates (bug
fixes AND new backward-compatible features) install automatically via
"composer update", while still trusting SemVer's convention that a
breaking change can only ever arrive in a MAJOR version bump - which
this constraint deliberately excludes. ~1.2.0 or 1.2.* would be overly
conservative for most everyday dependencies, missing out on genuinely
safe new features, and would only really be worth choosing for a
package with a known history of accidentally shipping breaking changes
in minor releases.

Notes:
- This directly matches the chapter's own recommendation of ^ as the
  standard, recommended default constraint.
- The exact-version constraint (e.g. plain "1.2.0" with no prefix) was
  deliberately not chosen here, since it's the most restrictive option
  of all and was already flagged in the chapter as "rarely used, very
  restrictive."