Versioned Releases

Learning Library Design Patterns
#1

Problem

Despite everyone’s best efforts, we will find bugs in our hApps, add important features, etc. How to we manage these changes from the perspective of the users, developers, and administrators?

Solution

I’m just highlighting that this an open question for most of us out there as evidenced by things like this empty link: Guidebook: Creating Versioned Releases. I know there is some kind of work that is going to go into this so the question is more what kind of ecosystem expectations do we have. I could imagine that there is a lot of churn, dead-ends, and consolidation that can happen as a lot of h-apps are developed and the space settles down. This would mean that from the start we would need to be thinking a lot about the stuff that I think Learn more about Ceptr had some really good ideas on - how to design in a way that gives users a lot of flexibility, keeps data from getting stranded in old chains, and lets things improve regularly. Do I have to assume every upgrade is a minority fork until I get the majority to switch? New versions could be designed with migrate functions that let users opt to pull in all their old data or maybe there is some other approach in the works to solve this problem.

See Migration and versioning

Need help understanding some basic terminology and App IDs
#2

@abrahampalmer thanks for stubbing this. The long-term goal is to support migration as a built-in feature. It’s totally possible to model most of the future with app-level patterns right now, but anything we could write about would be very roll-your-own and subject to obsolescence. I’ve found it’s a constant tension — writing about things that don’t exist yet :slight_smile:

#3

But Paul, by you writing about them they DO exist :slight_smile: . This topic has bothered me all year and I also don’t know the answer, but since RedGrid is way down the biomimicry rabbit hole, for us it will be some ‘mutation’ / ‘evolution’ leaving behind the ‘junk DNA’. Or something. There needs to be some primary (primordial) signal built into every hApp that is checked so that no one is left behind if they haven’t logged in for months.

#4

@mikeg

heh, true, but I don’t want to see people wasting their time on building an incompatible implementation of a future feature. Evolution is good, but it also has resource costs.