Adopt a strictly SemVer-compliant versioning scheme

26 views
Skip to first unread message

Marcel Stör

unread,
Jun 17, 2020, 4:54:27 AM6/17/20
to pushy
I inherited a project that currently depends on Pushy 0.13.7. Not being familiar with the code base, Pushy or APNS but struggling to address a production issue with the Oracle JDK -> OpenJDK move (runtime) I checked https://github.com/jchambers/pushy/releases.

From the outset it looks like 0.14.1 should be a drop-in replacement. But, bang! With the patch(!) release 0.13.11 you broke package names and Maven coordinates. With the minor release 0.14.0 you broke a lot of API.

I feel that this is a really bad practice as it breaks the old POLA. Did you consider adopting a strictly SemVer-compliant versioning scheme?

Jon Chambers

unread,
Jun 17, 2020, 8:42:52 AM6/17/20
to pushy
Thank you for your input.

I intend to move to strict semantic versioning with a 1.0 release when the API is more stable. In the meantime, the README warns that the API may be unstable until a 1.0 release. Until then, patch releases are generally taking on the role that major releases would under strict semantic versioning. I take pains to write detailed change notes so folks can assess the impact of changes on their codebase.

You are right that the 0.14.0 to 0.14.1 update included a breaking API change. That was, as I have explained elsewhere, just a mistake on my part.

-Jon

Ross Bender

unread,
Jun 17, 2020, 8:53:53 AM6/17/20
to pushy
+1 for semver.

@Jon - out of curiosity, at what point will you consider the library at a 1.0 point? It seems you have some idea of featureset or completeness before this is accomplished.

I bring it up because I would guess others (myself included) don't view specific versions as conceptually, and therefore moving to semver at any point (with next release) would be just fine. In my opinion, a version number is just something used to identify a point-in-time, so something higher or lower than a "1.0" release doesn't really matter. Plus, the library definitely seems like it's past any concept of pre-release stage.

Just my two cents. Thanks for all your work!

Marcel Stör

unread,
Jun 17, 2020, 8:57:59 AM6/17/20
to pushy
Thanks for the feedback!

The release notes saved from making "bad" decisions. The "right" decision for me was to bump to 0.13.12 for now. So yes, the release notes really help a lot.

Whenever I write release notes for my own open- and closed-source projects it's exactly experiences like this that help me find the right perspective.

Jon Chambers

unread,
Jun 17, 2020, 9:36:43 AM6/17/20
to pushy
> at what point will you consider the library at a 1.0 point? It seems you have some idea of featureset or completeness before this is accomplished.

I'm thinking—and have been for a long time—that the path to 1.0 is to do one release that supports multiple topics/credential sets per (currently planned as 0.15), expect that will turn into something of an "opinion volcano," then do one more release to address that feedback. That follow-up release is likely to be 1.0.

> I bring it up because I would guess others (myself included) don't view specific versions as conceptually… Plus, the library definitely seems like it's past any concept of pre-release stage.

Well, thanks for the vote of confidence! I think that's reasonable, but still think I'm going to hold off until multi-topic clients are in place because I believe that change will be large, disruptive, and happening in the near future.

Cheers!

-Jon
Reply all
Reply to author
Forward
0 new messages