If I install the beta version, will I lose my work?

[MrDaisyBates]

I'm assuming once you get the .taskboard file completed, this won't be the case, but as of right now, I'm using the normal install of Task Board (from the community plugins section). I'm assuming the way you have maps and such set up for now, I'd need to disable the existing plugin, use the BRAT for the beta, and I'd show back up and my map would be reset, etc?

Would any of my settings persist through this? I know the dependencies are saved into the actual task as you previously stated.

I'd be happy/eager to test the beta, but I do generally use it for my actual work. I know you suggest messing with a sandbox vault, etc. I don't really have anything low-stakes enough that I'd bother messing with it on, etc. I kinda have my whole life in one vault so to speak.

Anywho. But yes. I'm mainly confirming my suspicion that, at least in the current format, it's probably not safe/wise to install the beta.

Btw, keep this scenario in mind for your upcoming release (2.0.0, I believe, where the .taskboard files will be there). It'd be ideal that one could flip from one install to another and it all be portable enough that Task Board can pick right backup with zero hiccups for the user. I'm sure you're intending for that. Lol. It'd def be my biggest hurdle for personally participating in a beta, though.

[tu2-atmanand]

First thing I want to highlight in bold letter :

"Never use beta version in your personal vault"

and

"Never enable experimental features in your personal vault"

Now, let me give the short answer, for now, so you get the resources to use. But I have a lot to say on this topic, so will join in later to talk on more things.

We have a guide which explains how to test a beta version : https://tu2-atmanand.github.io/task-board-docs/docs/Advanced/HowToTestBetaReleases/

From this guide, only refer the first method, "Download a test vault and start testing".

In the release notes of the latest beta version, you will find a link to download the zip file. Simply download the zip, extract the folder. There will be a folder named "Task_Board_Testing". Now, from Obsidian, open this folder as vault : CTRL+P > Type Open another vault and select that option > Open folder as vault > Then select the folder you have just extracted.
And you are all set!

A new window should open which will be a completely different vault from your personal vault. Your personal vault data is never touched when you do anything in this testing vault. Also, using this downloading zip file method you need not worry about installing the BRAT plugin and everything (But ill explain more about this plugin later).

(While writing this answer I realized I can improve that guide from the docs so much and also I have got a lot of more ideas to add more documentation pages. Ill be back...)

[MrDaisyBates]

Hahaha. I appreciate you.

I will say, I am relatively risk tolerant and I do make somewhat regular backups of my vault. I don't mind being a guinea pig. I am a Linux user, after all.

But I didn't know there was a premade test vault. That's pretty cool. I'll need to look into that. Even opening a test vault, though, wouldn't I have to disable the plugin and enable the BRAT one? Wouldn't that still break the plugin in personal vault either way, since I'd be disabling and reenabling it?

[tu2-atmanand]

Even opening a test vault, though, wouldn't I have to disable the plugin and enable the BRAT one? Wouldn't that still break the plugin in personal vault either way, since I'd be disabling and reenabling it?

Not at all. That's the beauty of Obsidian (but sometimes it can be also a pain). Each vault is like a completely different Obsidian application. What you are doing in one vault doesn't affect the other vault. That's why the Sandbox is so famous, it's a completely seperate environment running.( You can easily copy your whole configurations from one vault to another, if you know how to do this). But two vaults running on your same PC are completely independent and they don't share anything with each other, just like a normal folders on your PC.

You don't have to touch anything in your personal vault related to Task Board.

Also, don't worry about the BRAT plugin I have installed inside the test vault. I could have given that vault without the BRAT plugin. But it has a very important role to play. And I guess you gonna love BRAT once I explain what it can do.

Just extract the folder from the zip file, open it inside Obsidian and start testing it out. No need to disable or enable anything.

[MrDaisyBates]

Thanks for all the tips!

So, I'm going to close this now because I assume the answer is, "yes, you will lose your work if you enable this on your vault."

[tu2-atmanand]

Okay, I got some time so I will talk more on this topic so other readers can be benefitted from this topic...

Why testing is important

I think, I need not have to talk much on this question. Everyone knows the importance of testing in a software development lifecycle (SDLC). A major part of the SDLC is dedicated to this phase and testers as well as common users are given the chance to test the latest features before they are shipped as final version for public to use. This is because, every user has their unique setup, no one can guarantee what setup the user is using, because each user will have a set of softwares installed on their PC. Each of their versions will be different, and each user has their unique way of using their PC. So, all these things are difficult to think of during the development of the feature. But, when users use it, that time we find out, this new features can be used a particular way too with a particular software. And, then we can enhance our new feature, so it works that way.

Hence, testing has immense importance and we should put most of our focus on this phase before making the feature as our daily driver.

How testing is done

Now, big companies have their massive Testers teams to test out their new feature. But, most of this companies also ship their new features for their users to get a chance to test out the feature.

Usually this is done using two famous methods (that I know of) :

1. Using beta version
2. Shipping inside a normal version as an Experimental Features

1. Using beta version

I havent personally seen this big companies using it. And it usually is not done for full-flaged softwares. Because the painpoint of this method is that, user will need to uninstall the previous version completely from their software and they will need to install the new beta version.

A beta version is completely similar to a normal version, except only their name will have beta mentioned on them. For example, a normal version which is planned to be released on 4th April 2026 will be named as "Task Board v1.10.0". But, for users to test it out, beta versions can be released with the name "Task Board v1.10.0-beta-1", "Task Board v1.10.0-beta-2", etc...

So thats what a beta version is all about. This beta versions are not shipped through a normal CI/CI pipeline. So users might not able to download it directly, they will need to use a different pipelines/sources to download and install it.

2. Experimental Features

This is a very common method we will see in a lot of big softwares. What basically done is, say a company has created a new feature in their software called, feat-A. And they are planning to release this features inside the version, 1.2.0.
Then, this company will already finish this feature and will ship the feature inside the previous version release, 1.1.0.
So, the feat-A will be already present inside the version 1.1.0. But, it will be in disabled state.
And the company will mention that in their version 1.1.0, they have an experimental feature which their users can test out to help make the feature error-proof and make it ready to be released as normal feature, when the version 1.2.0 will be released.

How testing is done in Task Board

In this plugin, we follow both these methods.

1. Using beta version

For this method, you will see that, we already have a wiki in our docs : How to test a beta version.

Everything is mentioned clearly in the above wiki with two approaches. Please go through it.

2. Experimental Features

In the version, Task Board v1.9.x, you will see that there are following experimental features which were released, as shown in the below image :

This setting is by default kept as Disabled state, which users can enable, which will enable all the experimental features present in this version so users can test them out.

(*Apologies for not adding a NOTE that users shouldnt enable this features in their normal vaults, but since these features didnt impose any serious issue hence it was kind of safe. But still, ill mention it next time not to enable the features in their day-2-day vaults.)

After giving a good amount time for users to test these features out, the next version will be released, Task Board v1.10.0, where all (or some) of these experimental features will be released as just any other normal features for users to use it normally.

But...

There are few features/changes which cannot be released as "Experimental Features" method for users to test out. I dont know if y'all know this, last month Atlassian company migrated their famous software Jira from Jira DataCenter to Jira Cloud. This is a huge change and hence cannot be released in their older Jira software itself for testing purposes. Hence, any user who wanted to test out the new Jira Cloud had to use it separately. Fortunately, these are all Web Applications, hence you can simply open Jira DataCenter on one tab and Jira Cloud on another tab in your browser so the testing was easy for this, but for installable softwares, this is very difficult.

Those who are aware, Task Board is now migrating from Version 1 to Version 2, where there are some architectural level changes done to this plugin. Hence, these new changes are not possible to be released as "Experimental Features".

Also, just a quick learning point, whenever any software move from version number like 1.x.x to 2.x.x (that is when the first number has incremented) that means, rolling back to previous version is very difficult. For example, its easy to roll-back from version, 1.8.0 to 1.7.0, if you dont like anything in the new version. But in major version changes, its usually is not possible, unless a fall-back guide is provided.

Ill try to provide a fall-back guide along with the migration guide.

[tu2-atmanand]

Why BRAT plugin is so powerful

You might have seen in the wiki for testing beta version, I am using the BRAT plugin. The revolutionary feature of this plugin is that, it kind of provides second realm of the Obsidian's Community plugins. That is, in the official Community plugins page, you can only install the latest version of the plugin, also only the plugins which are approved by the Obsidian team are available.

But in the BRAT plugin, you can basically install any plugin, whether it has been approved or not, and most importantly any version of the plugin. That is, you might have seen, every plugin releases their versions on GitHub. And GitHub is humble enough to store all of those previously released version. For Task Board, here are all the previously released version so far : Task Board versions.

Now, lets say a user dont like any feature from the latest version, 1.9.0 and they want to go back to the previous version, 1.8.0 (or 1.8.7), then Obsidian dont have an official way to achieve this. The one option is manually downloading the artifact from that version release and then creating a task-board folder under the .obsidian/plugins/ and then placing all those downloaded files under that folder.

But, the BRAT plugin makes this job easier for your. It has a setting, where you simply add the GitHub link of the plugin and then simply select whichever version you want to go to. The best part, you can even select beta version as well.

In the Task Board wiki, you will find a step by step guide on how to use the BRAT plugin : How to test a beta version using BRAT.

Downside of using older version

One thing you should keep in mind is that, there might be few issues in the previous version which might have got fixed in the latest version. Hence, you should make sure that, if you want to rollback to a previous version, say 1.8.0, then roll-back to the latest version in that series, that is 1.8.7.

But, its not always guaranteed. There might be a bigger issue which has been fixed on in the version, 1.9.0. So, if the developer has time, they can support the previous version series 1.8.x and can release a new version, 1.8.8 just for few users who are requested for that. But thats usually not seen in an open source arena. Previous versions reach their end-of-life as soon as new versions are released.

(I am planning to support the Version 1 series of Task Board for atleaset 2 months after the Version 2 series has been released.)