swephrs v0.17.0 is tagged — the release the #37 audit was aiming at, and the point where the audit-era consumer migration finally happens.
https://github.com/morphatic/swephrs/releases/tag/v0.17.0
Why you are getting this
This repository reaches swephrs through astrologica and morphemeris rather than depending on it directly, so there is most likely no code change here. It is on the migration list because a transitive version bump can still move numbers, and because the audit changed a lot of them.
The migration runs in dependency order and this repo is downstream of the first two:
- astrologica — astrologica#57
- morphemeris — morphemeris#125
- this repo, once those are tagged
What to expect
Almost certainly: a pin bump and nothing else.
Possibly: values move. The audit fixed real defects and the numbers changed accordingly — always toward the C Swiss Ephemeris reference. The ones most likely to reach a downstream consumer:
- Placidus house cusps move up to 18.25° in the last degree of latitude below the polar circle (v0.15.0). Above the circle nothing changed.
- House angles — ascendant, vertex, co-ascendants, polar ascendant — change on and near C's
Asc1/Asc2 discontinuities (v0.16.0). Not measure-zero: 0.233° wrong at 1e-7 from the polar bound.
- Every heliacal event time moved, up to a few days at ancient epochs and ~74 s at all epochs (v0.14.0). All six Moon heliacal event types now return an error rather than a date (v0.17.0) — see morphemeris#125 for why that is half a parity fix.
- Sidereal house cusps under the epoch-anchored modes (J2000, J1900, B1950, Skydram) changed convention, including Whole Sign cusps no longer landing on multiples of 30 (v0.14.0).
- Nodes, apsides and orbital elements all moved in v0.10.0.
- Topocentric positions at ancient epochs move up to 2.3e-2° at 3000 BCE (v0.17.0). Modern dates are unaffected.
Re-baseline any golden-file or snapshot test that bottoms out in one of those.
If this repo does depend on swephrs directly
Check for these, in rough order of likelihood:
calc_body / calc_body_ut now return Result<Outcome<BodyPosition>, EphemerisError> (v0.17.0). Previously a rejected call came back as Ok with a zeroed BodyPosition — indistinguishable from geocentric Earth, which is a legitimate [0, 0, 0]. If anything here has ever shown a body at 0° Aries unexplained, that is now an error naming its cause.- The longitude-crossing functions gained a trailing
flags: CalculationFlags (v0.6.0); CalculationFlags::default() reproduces the old behavior.
estimate_daily_motion was removed (v0.6.0) in favor of mean_sidereal_daily_motion and mean_geocentric_daily_motion.NodeMethod became a bitflags struct (v0.10.0).NutationCache, EphemerisContext::nutation_cache() and EphemerisWarning::Circumpolar are removed, and the moshier module is private (v0.17.0). MoshierProvider is re-exported at the crate root; swiss_ephem::{SwissEphemerisProvider, required_files_for_jd} are unchanged.
Note on CI
The downstream (astrologica) job in swephrs only ever caught compile breaks, and it stands down entirely once a declared breaking change lands. None of the value changes above are visible to it. Verifying them is the consuming repo's own tests.
Refs morphatic/swephrs#34, morphatic/swephrs#37.
swephrs v0.17.0 is tagged — the release the #37 audit was aiming at, and the point where the audit-era consumer migration finally happens.
https://github.com/morphatic/swephrs/releases/tag/v0.17.0
Why you are getting this
This repository reaches swephrs through astrologica and morphemeris rather than depending on it directly, so there is most likely no code change here. It is on the migration list because a transitive version bump can still move numbers, and because the audit changed a lot of them.
The migration runs in dependency order and this repo is downstream of the first two:
What to expect
Almost certainly: a pin bump and nothing else.
Possibly: values move. The audit fixed real defects and the numbers changed accordingly — always toward the C Swiss Ephemeris reference. The ones most likely to reach a downstream consumer:
Asc1/Asc2discontinuities (v0.16.0). Not measure-zero: 0.233° wrong at 1e-7 from the polar bound.Re-baseline any golden-file or snapshot test that bottoms out in one of those.
If this repo does depend on swephrs directly
Check for these, in rough order of likelihood:
calc_body/calc_body_utnow returnResult<Outcome<BodyPosition>, EphemerisError>(v0.17.0). Previously a rejected call came back asOkwith a zeroedBodyPosition— indistinguishable from geocentric Earth, which is a legitimate[0, 0, 0]. If anything here has ever shown a body at 0° Aries unexplained, that is now an error naming its cause.flags: CalculationFlags(v0.6.0);CalculationFlags::default()reproduces the old behavior.estimate_daily_motionwas removed (v0.6.0) in favor ofmean_sidereal_daily_motionandmean_geocentric_daily_motion.NodeMethodbecame a bitflags struct (v0.10.0).NutationCache,EphemerisContext::nutation_cache()andEphemerisWarning::Circumpolarare removed, and themoshiermodule is private (v0.17.0).MoshierProvideris re-exported at the crate root;swiss_ephem::{SwissEphemerisProvider, required_files_for_jd}are unchanged.Note on CI
The
downstream (astrologica)job in swephrs only ever caught compile breaks, and it stands down entirely once a declared breaking change lands. None of the value changes above are visible to it. Verifying them is the consuming repo's own tests.Refs morphatic/swephrs#34, morphatic/swephrs#37.