Save without increasing the version number

[stevekrouse]

A lot of folks ask for this. I'm not exactly sure how it would work. One idea is we could have a notion of "soft versions" that are tied to maybe a timestamp and not a hard version number. You can then do an explicit "new version number" save if you want. JSBin does a good job of that. Or maybe we could call these versions "minor version" and then allow you to create a new "major version". It could feel nicer to see v0.0.1 go to v0.0.2 instead of v1 go to v2.

Or we could simply hide and de-emphsize the version number in the UI. Maybe that could help people feel better about the number going up - not having to see it go up.

[nbbaier]

I really like the major vs minor idea

[pomdtr]

I feel like minor vs major version are a bit much for vals.

But in the other hand, I sometime want to work on a val without breaking val that depend on it.

I like the 'WIP' concept in GitHub pull requests, maybe it could be reused here ?

[Xkonti]

I agree with the "WIP" approach. This would require new versions to be "published" somewhat manually, which would complicate things from the perspective of the user flow.

Maybe an option to switch the Val to a WIP mode so that it's a opt-in feature?

This would for sure fix the problem of a val having 15 broken versions between 2 that actually work.

[neverstew]

I really like the simplicity of the single version number. It feels a little different to normal, but in a good way.
I totally agree that a WIP "branch" would alleviate most of the problems that I'm guessing people bring this up to solve.
Maybe it's just one that needs to be dug into more - this feature doesn't get to the root of why people ask for "save without versioning" (yet).

[pomdtr]

I think an interesting implementation would be too introduce a latest tag: import { add } from “https://esm.town/v/pomdtr/add?v=latest”

The latest tag would point to the latest non-wip val version (all version created while a val is in WIP state are WIP). By default all vals from your account will have this type of import.

When you work on a val, you can just set it to WIP (with a toggle). It allows you to update it without breaking your other vals that depends on it. If you want to test against the wip version, you can update your import: import { add } from “https://esm.town/v/pomdtr/add?v=wip”

By default, when you import a val from another account, it would default to the latest non-wip version of a val.

[stevekrouse]

I think we'll also need the concept of branching for other reasons, so maybe they could make sense here too... We'll need to think on this for a while

[stevekrouse]

Related:

https://discord.com/channels/1020432421243592714/1020432421243592717/1196970750016487424

[stevekrouse]

We could also implement something like autosave if we were able to divorce saving from versioning:

https://discord.com/channels/1020432421243592714/1208155607446851644/1209270009675784262

[thierryc]

The Figma Version History can serve as inspiration to start thinking about it.
Named versions are consistently displayed at the top.