this post was submitted on 26 Aug 2023
24 points (100.0% liked)
Experienced Devs
3902 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Context:
I'm a dev that consumes company wide libraries, not an author of such libraries. So the following comes from that perspective.
A couple questions:
My thoughts:
First off, SemVer is definitely going to be important. Also, it sounds like you're working toward API stabilization which is going help iterating in the future.
My idea 1:
If your library is made up of several isolated components, what about doing major releases (ex 2.x.x -> 3.x.x) more frequently? Only include a small subset of breaking changes for one or two components rather than jamming a whole bunch in there just because it's a "major version release". The result is you could move quickly and iterate while also minimizing the impact on ALL of your users every release. Some of your users may be able to upgrade to the latest without having to touch much or any of their code.
My idea 2:
Do frequent major release (ex 2.x.x - 3.x.x) but always start with an "alpha" release that early adopters could implement and provide feedback on. This would shield the majority of your consumer's code from having to iterate frequently but would also require you to enlist a group of committed early adopters that are diligent about iterating their code as often as you release.
Feedback on the original option 1 and 2
Option 1
This could work if your users are excited about your releases. But, it could result in people NEVER upgrading because it's too much work to do so. (I've seen this happen. No one upgrades until they absolutely have to.)
Option 2
Depending on the size of your company, this will be a lot of work for you and will slow you down. If you're using your users to vet out new features, then everyone is going to have to iterate frequently (like you said) if experimental changes don't work out.
Thanks for your thoughtful reply.
I like your idea of doing more frequent major releases and limiting the size of breaking changes within each release. It seems like a good compromise.
Hm. In that case, smaller more frequent breaking changes may also not be ideal. It sounds like no matter how small the breaking change, everyone who uses the library is going to have to update their code... and if it's happening frequently, that could get annoying.
This may be completely off-base, but just going off of what you said about data traversal, would it be completely out of scope for your library to provide a consistent interface for getting/traversing the data it is responsible for? Or do the consumers all use/traverse the returned data in very unique ways such that you couldn't really develop a "general" API of sorts.
This is actually something I've been considering. I think it would make sense for me to see what existing traversals could be upstreamed into my library. Some of them might be very domain-specific, but others might be generic enough to be generally useful.