Hi,
I think versioning in general is an important feature and versioning of each entity as a whole is not only useful, it is a requirement in certain compliance context.
To begin with, the rich text fields should have versioning (and afterwards diff view between versions, revert back to a specific version, etc. too).
In general, using an event-sourced architecture greatly helps with features like versioning, undo-redo, etc.
Thanks!
We have this idea in the backlog, however I doubt we will implement it till first release.
Yes, not a super high priority for first release.
Also agree here - I liked in Confluence the fact that you could revert to previous versions. The âRich Textâ field type functions similarly with you guys - although you have the advantage of this being an actual entity with all the great substance around entities! - so being able to revert to previous versions would be very useful and add some good wiki functionality.
Wanted to point this request out again. As a Fibery instance grows and more and more knowledge finds its way into the System, this is becoming a bigger need of ours. I think most other apps have this function, so would love to see it here. Would be grateful for any update on progress from the Fibery Team!
As an add-on to this request, when itâs implemented, Iâd appreciate the ability to be able to make relationships that are version-specific.
Ideally, I can choose to create a link that is either:
Woah, thatâs an interesting but complicated-seeming addition. Can you give an example of where this would be useful?
One use case I had in mind was for test cases and their executions. If I write a test case, and then execute it, it would be great if the execution only linked to the version of the test case that was valid at the time of execution.
If I edit the test case, I donât want the execution to link to the latest version.
Would love to see this type of sophisticated software dev capability in Fibery, but from my point of view could wait for it till later. Fundamentally though being able to see an activity record of Rich Text fields, and potentially revert versions would be great right now.
Coda has a great feature where you even get to back out during a session if you donât want to save it when opening a Rich Text box. It auto-saves every few seconds, but you also get to âsaveâ before you close the window, very convenient!
This is similar to Confluence I mentioned above.
I think some implementation of either of these would be very, very useful - Iâd make great use of it right away!!
Interesting. I can imagine other possible approaches to this that seem less complicated to me from a dev and UI/UX perspective, but Iâm curious to know more. Are the Test Cases and Executions both represented as their own Types?
Yes, I had assumed that using a type for Test Cases and a type for Test Executions made the most sense. If you have suggestions for how to solve the problem with fibery as it is, please let me know 
I basically want to define a Test Case (as a series of test steps: âDo thisâ, âMeasure thatâ, etc.) and a user can instantiate a linked Test Execution which contains the results of following the steps. If the Test Case is subsequently updated (e.g. remove the âMeasure thatâ step) I donât want the existing Test Execution to link to the revised Test Case, since they would be inconsistent. I want the Test Execution to link to the state of the Test Case at the time it was executed.
I suppose I could automatically copy the details of the Test Case into the Test Execution at the time of its creation, but that doesnât seem to be a very graceful way of doing it. Iâd much rather link to a historical version of the Test Case.
Gotcha. So to really try to resolve this Iâd probably need more info, and youâre probably right that versioning would help create a more ideal solution. However, without knowing more, I can see at least two other possible approaches off-hand, aside from copying the test case into the execution entity (and there may be more with some more thought and/or knowing more about the workflow).
1: Define the test cases in a Rich Text field, with check boxes or whatever you prefer. And delineate each version with a header (H1), e.g. âAssembly test case #45 V1.0â. Then somewhere in the body of that section of the text, link to the Test Execution Entity for when you run that test. When you update the test case, copy/paste everything you want to update from it, create a new header âAssembly test case #45 V2.0â, collapse the previous one, and paste in the V1.0 contents and update. A little manual work, but not too bad, and you keep all the versions in one place.
Iâve shown a pseudo-example in the image below. Obviously Iâm linking to the wrong entity, in this case the Test Case itself. You can see the previous test case is collapsed at the bottom. I just copy/pasted the bottom one to make the top.
2: Another option might be to create a âselfâ relationship in a 1:1 configuration for the âTest Caseâ Type and name the two resulting fields âprevious versionâ and ânext versionâ. Then when you need to update the test case, create a new version and link to it in the ânext versionâ field, copy the contents of the old, go to the new, paste, and edit as-needed. Any Executions of that version of the Test Case get linked as normal in their own 1:1 relationship field. Again shown in my example image, this time outlined in blue, and obviously the relationship to âtasksâ here in my test Type would for you be a link to the âTest Executionâ.
Obviously all of these involve steps like copy/paste which you might see as being too much work for your needs. And these ideas may be totally non-workable, or just not an improvement on what youâre already doing. One thing Iâll say that I think this makes clear is that a âcopy entityâ function would be nice.
Part of what would be good to know to try to come up with better options is what really are the âpain pointsâ of your existing workflow, i.e. what takes the most time/effort and what other problems arise from these versioning issues, how often does versioning happen, how many maximum versions are you likely to have, etc.
Iâm also curious if any existing tools that you know of already handle this well and could be used as a good model.
Having said all that, I definitely want document history and possibly versioning, i.e. named versions. Iâm just less confident about how to best handle the complexities of maintaining history on relationships, backlinks, etc.
I suppose one simple option for dealing with e.g. a deleted entity would be to maintain the name of it in any entities it was linked to, in their history state, and the live link just doesnât work. Or, alternatively, to maintain a read-only archive of the deleted entity in the state in which it existed when it was linked from the version of the entity youâre looking at. But even trying to describe issues like this starts to make my head spin and is one reason Iâm wary of wanting to rely on this kind of deep and complex version handling.
Iâm glad I donât have to actually implement solutions to these problems and trust that @mdubakov and team will make good choices moving forward. They have done well so far.
Very thoughtful response, thank you.
In the past, I have occasionally followed the #2. solution you described, and as you say, it becomes a whole lot more workable when there is a âcopy entityâ function (+ ideally a âlock entity for editsâ to ensure the v1.0 is not accidentally used).
But yes, I can well imagine that there are many situations where being able to link to specific historical versions creates a lot of what-if questions. Thatâs probably why Iâve never encountered a solution that I truly love. Maybe I should not wish for this feature after all(!)
As a compromise, I have tried to implement a flag that would indicate if an entity has been changed since the last time it was âapprovedâ so that anyone viewing the entity can make a value judgement on whether or not any existing related entities are still valid, or if they also need updating. Itâs sort of related to what some software tools implement as âMark as suspectâ.
However, the hassle of implementing this for every type where this kind of flagging would be useful has somewhat put me off.
(this is one of the reasons why I had previously suggested the possibility of Fields applicable to all types which I know generated a fair bit of discussion!)
As you have said (here and elsewhere) the fibery team seem to have a very good idea for what adds value and how best to implement, so I have also decided to hold off making major feature requests for the time being. Instead, I just look forward to seeing what they bring out and working out the ways it can be useful to me.
But I still love reading these forums to hear what challenges other people have and how they solve them 
Yes, same! I always feel that a good community and the ability to have open dialog, even when there is some disagreement, is a really good sign.
One thing I love about it here so far is itâs very practical and work-oriented. There is very little over-the-top idolizing of the product or mysticism about its team. This may just be a product of the lower market penetration vs. e.g. Notion or Roam, but both those products have really annoying/unproductive aspects of their respective communities in my opinion (cult-like is a term thatâs been used 
).
So while I donât wish for Fiberyâs community to remain small as it is now, I do hope we can maintain the more realistic approach, open dialog, and helpful nature as it grows. 
And @Chr1sG, I am curious how much either of you have dabbled in TargetProcess? There was an interesting Test Case module that I liked.
In a Fibery context, as far as I can tell, this would just be tweaking some attributes around Apps/Types to duplicate that functionality, but we donât have the capabilities yet as some views are missing, and TargetProcess was all about hierarchyâŚyes, that subject again
On a broader level, I am hoping to see a lot of what Michael, presumably, conceived in TargetProcess soon in Fibery. Another great piece in there was DashboardsâŚhmm. While Iâm at it, in fact a lot of what weâve been discussing was handled very well in TargetProcess. Where I fell down in TargetProcess, and what Fibery solves, was the ability to more liberally relate items. You couldnât do it there. The hierarchy was great, but that tool was all about top-down hierarchy I would day. The basic entities were cascading down in this data model:
You worked mainly within that. So if you wanted to create an Entity on the âtaskâ level, it had to first be âsubâ to a âuser storyâ before relating up to the âfeature.â
TargetProcess had âfreeâ relations though, too, which were useful - you could see them on boards I believe. So weâre getting into our âpolymorphismâ discussion, too.
Letâs hope all of the good in TargetProcess makes its way over to Fibery ultimately!
I never tried TargetProcess, but Iâll probably have a look at it over the weekend
Great examples, thanks! Given Targetprocess handled this well, I have even more faith Michael and team will figure out how to address this kind of need (and much more) with Fibery.
Thanks guys @Oshyan and @Chr1sG for weighing in! Would love to hear your thoughts, I think you can run through the TP marketing site and get a good feel for it. Unfortunately theyâve gone Enterprise so no easy way to quickly get a demo account these days over there 
If we could get the basics out of TP here in Fibery that weâve been talking about - hierarchies, dashboards, better notifications, apps, simple relations, etc., my needs for Fibery would be 100% solved. I agree Oshyan that in principle I think the team here should be able to replicate that since in essence Michael was involved in that stuff. But candidly, I donât see a lot of response to many of the suggestions Iâve posted around here, and mentions about stuff in TP and when weâll see it here. If you have a look at some really good posts from @Shafqat_Ullah, who sadly I donât see too active any more, he points out a ton of the good stuff from TP as I have assumed he was a longtime user. This very post is his in fact!
Thanks guys and very eager to get your thoughts on this particular point! I am still having a lot of trouble in Fibery with my team without these basicsâŚso desperate to try to figure out when, or more nervously - if - they are coming!
And hey, have to agree 100% with the cult aura around both Notion and Roam, Roam worse I think. Neither of those tools doing much feature delivery of late eitherâŚ
Hoping Fibery continues to delivery useful features, but would like to see more guidance around some âteamâ stuff I just mentioned that weâve been discussingâŚ
Not sure if you noticed (I often miss it), but I do believe Michael marked this as âApprovedâ, i.e. âwe will implement this feature requestâ just a day or so ago. Of course that does not indicate a time line, but itâs a promising first step, and some âengagementâ with the request, at least.
I would also say that, although they do not have a public road map, their dev pace and look-ahead (a month or two on each blog post) is a lot better than you get with either Notion or Roam, or a lot of other products. So while I totally get you wanting to have this ASAP, we donât know when itâll be, but it is at least âcomingâ⌠
