How do you balance rapid iteration and merging/upgrading? (programming.dev)

submitted 1 year ago by tatterdemalion@programming.dev to c/experienced_devs@programming.dev

24 comments fedilink hide all child comments

More specifically, I'm thinking about two different modes of development for a library (private to the company) that's already relied upon by other libraries and applications:

Rapidly develop the library "in isolation" without being slowed down by keeping all of the users in sync. This causes more divergence and merge effort the longer you wait to upgrade users.
Make all changes in lock-step with users, keeping everyone in sync for every change that is made. This will be slower and might result in wasted work if experimental changes are not successful.

As a side note: I believe these approaches are similar in spirit to the continuum of microservices vs monoliths.

Speaking from recent experience, I feel like I'm repeatedly finding that users of my library have built towers upon obsolete APIs, because there have been multiple phases of experimentation that necessitated large changes. So with each change, large amounts of code need to be rewritten.

I still think that approach #1 was justified during the early stages of the project, since I wanted to identify all of the design problems as quickly as possible through iteration. But as the API is getting closer to stabilization, I think I need to switch to mode #2.

How do you know when is the right time to switch? Are there any good strategies for avoiding painful upgrades?

you are viewing a single comment's thread
view the rest of the comments

[-] thelastknowngod@lemm.ee 5 points 1 year ago

Yeah for this situation, versioned APIs are the answer. If, for example, you look at the kubernetes ecosystem, the entire thing is based on APIs and every resource starts by specifying an api version on the very first line.

apiVersion: v1
kind: Namespace 
metadata: 
    name: example-namespace

This is how they can make upstream changes and not break existing environments in the process.

[-] tatterdemalion@programming.dev 1 points 1 year ago

I'm not suggesting that my library is unversioned. It's totally version controlled, and users can upgrade to whatever revision they want to pull in the changes. The changes I make upstream don't affect anyone downstream until they decide to upgrade. It could even adhere to SemVer, but my problem remains: how to minimize rewriting user code? Is it better to have more small upgrades or fewer large upgrades? When is one strategy preferable to another?

[-] thelastknowngod@lemm.ee 6 points 1 year ago

SemVer seems logical. If most of your changes are breaking, I don't think it really matters if you are releasing often or occasionally though.. If it's often, the users will get fatigued with upgrades. If it's occasionally, they'll be overwhelmed and push it off.

If most of your changes are breaking, you should just disclose that the software is in an alpha/beta state and that it can't be depended on to remain consistent until you have a defined policy about what gets released and when. It will be up to the users to decide if they are comfortable with those terms.

load more comments (4 replies)

this post was submitted on 26 Aug 2023

28 points (100.0% liked)

Experienced Devs

3961 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

snowe@programming.dev

jmk1ng@programming.dev

drewsiferr@programming.dev