search

syrusakbary / snapshottest

Snapshot Testing utils for Python 📸
MIT License
525 stars 102 forks source link

RELEASE 1.0.0b0 #141

Closed paulmelnikow closed 3 years ago

paulmelnikow commented 3 years ago

These are the commits: https://github.com/syrusakbary/snapshottest/compare/0.6.0...master

@medmunds mind taking a look at this too?

davidshepherd7 commented 3 years ago

Hey, not sure what exactly you want reviewing here but releasing a 1.0 beta seems fine.

Can we merge #112 first?

paulmelnikow commented 3 years ago

Mainly the changelog. I don’t want to block on #112 to get validation on the Py3 updates. We can easily ship another beta. I’ll give #112 another read though.

medmunds commented 3 years ago

I'd kind of like to see #112 in before a 1.0-beta. Also, if we're about to introduce new django (and unittest) entry points and deprecate the old ones (#52 (comment)), I kind of think that should go in before the beta, too.

Could I suggest maybe releasing the current code as either 1.0-alpha, or maybe even just 0.7.0? My sense is very few people install pre-release versions, so if the goal is getting feedback on recent changes, 0.7.0 will maximize that. (Before 1.0, semver permits breaking changes in 0.x.0 releases.)

(I was always taught that after you reach beta, you should try to stick to bugfixes only—new features and API changes are strongly discouraged between beta and release. Though I realize different organizations have different definitions for beta.)

paulmelnikow commented 3 years ago

(I was always taught that after you reach beta, you should try to stick to bugfixes only—new features and API changes are strongly discouraged between beta and release. Though I realize different organizations have different definitions for beta.)

In Nock we shipped new features and breaking changes in beta releases for a whole year once. Though yea, different orgs and programming communities may have different expectations. I think the reason to make them betas is to signal that we prefer people use them and give feedback. Although I really don't mind releasing a bunch of alphas instead.

(Before 1.0, semver permits breaking changes in 0.x.0 releases.)

This is why I want to get into 1.x territory. Below 1.0, semver is pointless.

112 still needs documentation. How about I ship this as 1.0.0a0, and then we can ship 1.0.0a1 after #112 lands?

Though major versions are expensive, releases are cheap.

medmunds commented 3 years ago

@paulmelnikow could you tag this release in git? (I think the GitHub Releases page will offer to do that for you if you add a release there.)

paulmelnikow commented 3 years ago

Oops! All set.