Repository navigation
Coordinating changes with HTTPX #59
Description
Since we're now officially using HTTPCore in HTTPX I thought it'd be good to define a policy for coordinating changes between the two.
In terms of releases, and given we're using semantic versioning, we could go:
- Strict, each HTTPX release depends a specific version of HTTPCore.
- Pro: there's no ambiguity on the code behind each release of HTTPX.
- Con: we'd need to make releases in pairs, HTTPX might require a release with only a bump in HTTPCore version.
- Lax, HTTPX depends on bugfix (minor?) versions of HTTPCore.
- Pro: We could release bugfix versions of HTTPCore independently of HTTPX.
- Con: Adds a certain ambiguity on the code per release which may complicate debugging issues.
Which ever we choose we should probably also define development workflows. For instance, I've seen repos that immediately after a release a version bump is merged indicating a new "development cycle". Another option is to enforce a version bump on each PR, or at least an entry in the Changelog describing whether the change should be considered bugfix, minor or major.
It's possible encode already has a policy but I thought it'd be good have an issue where we define it. 🙂
Thoughts?
Activity
florimondmanca commentedon Apr 15, 2020
Thanks for opening this :)
For the changelog, usually we populate the changelog as part of a release PR, ie just before issuing a release. So we’re already logging changes as Added/Fixed/Changed/etc. So from my POV there’s no extra action required - are you thinking about something else?
As for versioning, IMO there shouldn’t be any particular relationship between HTTPX and HTTPCore. HTTPX should treat HTTPCore as any other dependency, and pin it to an appropriate level. Both lax and strict options comply with this, which is good.
AFAIU, strict = depend on a bugfix release, lax = depend on a minor release.
As you noted, both have pros and cons; from my POV there’s no definite winner.
As of HTTPX master we are using lax, ie we’re depending on
0.7.*. So we can probably keep rolling with that, and reassess if we’re having too many issues?lovelydinosaur commentedon Apr 15, 2020
So, it ought to be dictated by API versioning. We'll stick with
0.7.*for now, but really we're aiming for1.*and given that we've really narrowly scopedhttpcorewe'd hope to not have to worry about switching from that for a decent period of time.yeraydiazdiaz commentedon Apr 15, 2020
Thanks all.
So, if I'm hearing this right:
httpcore, we look at the unreleased changes and decide if they're worth a bugfix or minor version.Is that a valid summary?
florimondmanca commentedon Apr 15, 2020
Yes on my side. Note that eventually it looks just like a regular SemVer-complying workflow. :-)
Small bit:
As I tried to describe previously, up to now we've been doing this in batch at release time - i.e. we aren't updating an "Unreleased" section of the changelog on each PR. (I think we discussed this before, but tl;dr is lower contributor burden and okay maintenance effort at release time.)
yeraydiazdiaz commentedon Apr 16, 2020
Cool, thanks all!