Question about compatibility policy and deprecation path for breaking changes

[higorprado]

Hi,

First of all, thank you for your work on den. I have been using it in my own NixOS repo, on a test machine, and I generally keep up with the latest version. I do that fully aware that some instability is part of using a fast-moving project.

I am raising this mainly because I like the project and want to see it become easier for more people to adopt with confidence.

Some recent changes have caused regressions in configurations that were working before. The removal of bidirectional is the latest example that made me more concerned about compatibility over time.

I completely understand that the project is evolving, and I am not expecting full stability guarantees. My question is more about whether you have plans to make this kind of transition easier for downstream users.

For example:

• Do you plan to reduce the chance of new changes breaking setups that worked before?
• Do you see value in introducing some kind of deprecation path for behavioral changes?
• Even if breaking changes are necessary, would you consider warning users in advance so they have time to adapt their repos?

Thanks again.

[vic]

Hey! Thanks for asking,

Yes, Den is currently at v0, I'm very happy and thankful for all people using it, and it is precisely because people are using it (and not only me) that I've got feedback from its users, some of which I have conversations privately and have helped migrating their infra. In doing so, people have contributed with very good feedback and use-cases. For example, the recent bidirectional removal began as we talking at Matrix about dups and also while helping others migrate their repos. So, given that people is using Den, they are actually shaping it. I like that very much, because otherwise some stuff like bidirectional that previously was part of Den core was just something not needed. We had a "routing example" that some other Den contributor then moved as what is now den.provides.mutual-provider #236, that contribution made us wonder if the built-in bidirectionality could be extracted from core #273 and then further conversations led to actually removing it #300.

So, change is inevitable, since we are trying to make Den better, not just cause incompatibility. Things that need to be fixed or removed (like bidirectional) should be removed as soon as possible, before more people depend on it.

That being said (I'm not sure how much you follow Den announcements and Zulip Matrix channels) we DO have announcements for people using main branch, and have also documented Den versioning, having a latest tag was also idea of another Den contributor #276.

For now (at v0) I believe the latest tag is sufficient for people not keeping with main and moving only between release points. We also have release notes that detail what changed and important things that hopefuly people DO read (because I do take time to write them).

I expect that Den will reach 1.0 very soon, maybe a month or two. And then will not have as much changes to the surface API.

[higorprado]

Thanks for the detailed reply.

As a software developer myself, I do understand the reasoning. I also understand that Den is still at v0, that change is expected, and that some things may need to be removed quickly when they are not the right long-term design.

Also, just to clarify one point: I do not use Matrix, but I did read the documentation and release notes.

What was frustrating on my side was the sequence of events in my own repo.

Until March 17, I was not using den._.bidirectional. A few days earlier, on March 13, I had actually migrated one part of my repo to a more Den-native routing pattern using den._.mutual-provider and provides.predator, and that was working.

Then, after the upstream routing change, my configuration broke. I spent quite a bit of time debugging it and eventually understood that, under the new model, the correct fix was to adopt den._.bidirectional to restore that host→user re-entry. I also had to refactor several host-only NixOS blocks into guarded perHost/take.exactly patterns to avoid double declarations. After all that, I finally managed to stabilize the repo again.

And then, shortly after that, bidirectional was removed.

So from my perspective as someone still new to Dendritic, and much more a user than an expert when it comes to NixOS internals, that kind of transition ends up being frustrating. Not because I object to change itself, but because I had just finished adapting to what seemed to be the correct new approach.

My intention was not to criticize the project or its direction. It was only to suggest some clearer kind of marking in the documentation, release notes, or another visible place before code is removed, so users can understand when a transition is temporary and have some time to adapt.

Thank you again for the work on Den. I have genuinely been enjoying it. I even published a LinkedIn article explaining why I started using it.

My intention here was only to help by sharing feedback from the perspective of someone actively trying to adopt it.

For reference, this is the repo where I have been using Den:

https://github.com/higorprado/nixos

[vic]

Yeah, I understand your perspective. I try to be as open as possible, I forward the same announcements from GH into both Zulip and Matrix, we also have a tangled.org mirror, because I know not all people participates on the same channels, they don't have to. For now while we are at v0 I'd suggest to keep an eye on GH activity, I really want Den to have a definitive API, I believe we are closer to that, because only then I can focus on Den social goals (at vic/denful). Thanks for using Den and thanks for talking to people about it, I know many concepts and idioms from it are not traditional not even to Dendritic flake-parts users. So I'd like to thank you very much for being one of the brave ones that actually give Den a try. I'm open to contributions, code, issues, documentation, release-process. Currently I'm the only one handling all that, but I believe in the future as more people participate we will also have better release/deprecation processes. At v0 this is a one man show, things will change as Den is adopted and contributed by more people. Thanks for using Den and being here.

[vic]

Btw, we have GH discussions for things like this. Issues are for me, since I allocate time to them from my very limited opensource time. I'll convert this to a discussion.

Btw2: I don't know what a Linked-in is, but please do share what you wrote about Den. :)