FR: Too rapid update

[NickLennonLiu]

Is your feature request related to a problem? Please describe. I'm always frustrated when updates are released too rapidly. It becomes challenging to keep up with the changes, especially when they introduce breaking changes or require significant adaptations.

Describe the solution you'd like I would like to propose a more structured release schedule. This could involve:

• Regular, predictable updates (e.g., monthly)
• Clear communication about upcoming changes, ideally with release notes available ahead of time
• A beta or preview period for major updates to allow for community feedback and adjustments before the full release

Describe alternatives you've considered An alternative could be providing a Long-Term Support (LTS) version that receives critical updates only, while a more frequently updated version remains available for those who prefer to stay on the cutting edge.

Additional context Frequent updates can be beneficial, but without a clear and manageable update strategy, it can lead to user fatigue and potential instability in projects dependent on this software. Screenshots of update notifications and a comparison of stable versus frequently updated project timelines can be provided if needed.

[zsviczian]

I understand, and I don't disagree. On Discord I share beta updates. Unfortunately I do not get much (often any) feedback... so it is not so simple.

You can turn off update notifications in plugin settings and only check for an update monthly.

Many of the updates do not originate from me but driven by changes implemented on Excalidraw.com and by Obsidian... since neither communicates about the features that will happen, there is not much prediction I can make.

I can fully see the issue with update fatigue. In terms of stability, there is a dilemma. Infrequent updates will lead to less stable overall performance since there are more changes that accumulate and the compound effect is much harder to solve.

---

What has broken for you that leads you to this statement? "potential instability in projects dependent on this software"

[zsviczian]

I could do the following: Minor interim updates bump the last digit of the release. Combined (monthly?) updates bump the middle number. Breaking changes (e.g. file format change) bump the first number.

Thus 2.2.1, 2.2.2, 2.2.3, ... are interim updates 2.3.0 is a monthly update 3.0.0 will come if there are some real big changes...

Of course to deploy such a strategy requires an update as well...

[zsviczian]

Case in point... Excalidraw just released elbow connectors. It was a complete surprise to me, but the feature is something I wanted for a very long time! Would it be better if such new features would come with a month's delay to Obsidian?

I posted a beta update in the testing channel, let's see if anyone responds...: https://discord.com/channels/1026825302900494357/1076960836901417092/1268665369753817138

[zergote]

Un buen ejemplo es que Excalidraw acaba de lanzar conectores de codo . Fue una completa sorpresa para mí, pero es una característica que quería desde hace mucho tiempo. ¿Sería mejor si estas nuevas características llegaran con un mes de retraso a Obsidian?

Publiqué una actualización beta en el canal de prueba, veamos si alguien responde...: https://discord.com/channels/1026825302900494357/1076960836901417092/1268665369753817138

I prefer to have fast updates. There are people who can't keep up to date, but that shouldn't stop everyone else from getting the latest updates.

[zsviczian]

Here's my current thinking:

[zsviczian]