2 ms·
Maybe I'm spoiled, which I'm willing to consider being true. However, one could assume that projects at this stage would use versioning, pinning, and documentin
by 0des 4y ago
Maybe I'm spoiled, which I'm willing to consider being true. However, one could assume that projects at this stage would use versioning, pinning, and documenting the changes to the api, which obviate the need for these types of disclaimers. All caps disclaimers like this could discourage those who are otherwise capable from giving it a shot.
Im not saying this is deno's fault, maybe it is and maybe it isn't, I'm only saying I'm noticing that rather than documenting through breaking changes people would prefer to make prominent disclaimers that are essentially buyer beware
- tuxie_ 4y agoI'm currently developing an "experimental" piece of software, i.e. I am not even sure some features I want to add are possible, meaning I had to rewrite it a couple of times (and won't be the last). Having strict versioning, pinning, and documenting everything before it reaches a semi-stable state would discourage me from developing it altogether. I agree with the approach they are taking, keep the disclaimer, put it out there, get some visibility to find early adopters and contributors and stabilize it. A year from now people will have forgotten about this thread and will see it a new and stable framework.
- schwartzworld 4y agoI think if you look at Angular as an example, the Aleph team is doing it right. Angular didn't just make breaking changes when they went 2.0, they basically abandoned everything about 1.x and released something completely new. There were definitely people who had just learned Angular 1 that found out their time was poorly spent.