Release versioning scheme?
dparis opened this issue · comments
When it comes time to cut a release, I'm considering the following versioning schemes:
- Numbering which tracks the phzr release version directly, something like 2.4.2-0 for the initial phzr release, incrementing the
-0for internal phzr updates - Traditional SemVer building up towards 1.0 once phzr is stable
I'm leaning towards the first option:
Pros:
- Gives clear indication of the underlying Phaser version
- Easy to handle pending 3.x release of Phaser
Cons:
- Potentially many versions which differ only by the trailing number for a single Phaser release
- No semantic versioning indicated for phzr consumers, i.e. 2.4.2-13 might be a major breaking release, 2.4.2-14 a minor bugfix
Since phzr is intended (at least for now) to be fairly thin wrapper around Phaser, I don't expect there to be a lot of added functionality which might cause phzr-specific instability between builds. However, that may change in the future if there's a lot of desire expressed for additional abstractions in phzr.
I'd love to get feedback if anyone has any thoughts or preferences.
My vote is semver, if for no particular reason other than it's relative standardization. An arbitrary-and-somewhat-specific-to-phzr versioning system will be alien to new adopters, that sort of defeats the purpose.... VS any joe schmoe like me jumping into the project and understanding the versioning outright.
@latros Thanks for the feedback! It's a good point that SemVer is more standard, and thus easier to intuit if you're unfamiliar with the project. I wasn't sure how standard the other scheme was in the clojurescript community; I first encountered it when setting up the phaser package for cljsjs:
a version (def +version+ "X.Y.Z-0") We use the library's version for the first semver digits major.minor.patch and we append a hyphen and a cljsjs revision count (starting at zero).
Since phzr, by its nature, tracks the underlying Phaser library pretty closely, I thought there was value in making that relationship more explicit in the versioning.
Do you think it would be too confusing to have 1.x phzr tracking the current 2.x Phaser.js version, and 2.x phzr tracking the forthcoming 3.x Phaser.js?
That's a good question. Working with libs in the past, I have historically found it hugely useful to know, at a glance, whether some wrapper or related codebase was up to date with its parent/relationship repository. I definitely see value in matching the two, so newcomers can get an idea very quickly whether phzr is up to date.
(In other words I hadn't attributed for that benefit in my original feedback, but matching the versions sounds much more appealing to me now)
Yeah, I've found that sort of version coupling useful in past projects as well.
I'll probably cut an initial release sometime next week if all goes to plan. I'm still leaning towards tracking version. I'll be thinking about it until then, and if anyone has any more feedback I'd be happy to hear it.
Have to agree with cljs's way of doing versioning. A semver scheme could be useful in the beginning when the wrapper is not yet complete, but once development is more about catching up with new Phaser versions and making sure the wrapper is still compatible with it, then cljs's scheme is much better.
On a related note, you're still developing this, right? I was thinking about starting a very similar project but then I came across yours - I'm interested in contributing. I see it's been over a month since the last commit though!
@Kauko Hello! Thanks for the feedback about the versioning scheme. I'm going to go with the cljs-style scheme when I cut a new version. And yes! I'm still developing this, though not very actively at the moment. I had a surge of work at my day job, so I've been focusing on other projects this last month. I figured I'd let this one lie until I either had more time or got additional feedback from other users, so thanks for the poke. 😄
I'm very open to contributions or collaboration, so if there's anything you'd like to add or prioritize work on, let me know. I might have some project time to spare in the next week or two. Cheers!