Oddbean new post about | logout
▲ ▼
LeoWandersleb | 9 months ago (raw) | root | parent | reply | flag 
 I find cluttering the Readme not good.

How about versions/releases of the spec. We tag a major version whenever there are breaking changes.
▲ ▼
fiatjaf | 9 months ago (raw) | root | parent | reply | flag 
 I don't like that at all. It adds more confusion.
▲ ▼
LeoWandersleb | 9 months ago (raw) | root | parent | reply | flag 
 The release history is normally where I follow changes of projects. To slap it onto the Readme ... an ever growing list of changes ... isn't how any project does it, so it's not really expected. If in one document, make a breakingChanges.md and link it in the Readme. The nice thing of a release history would be that one could easily find a summary not only of breaking changes but also new "features" and contributors could be mentioned etc. It would definitely something I would love to read as I can't follow all repo activity since a long time now.
▲ ▼
fiatjaf | 9 months ago (raw) | root | parent | reply | flag +1 
 I don't like putting it on the README either. I think such a document is likely to become outdated and useless regardless of where we put it.
▲ ▼
brugeman | 9 months ago (raw) | root | parent | reply | flag +1 
 Well anywhere we put it can become outdated if not maintained
▲ ▼
brugeman | 9 months ago (raw) | root | parent | reply | flag 
 That removes scarsity, and I have to remember to go to version history. Still better than nothing
▲ ▼
LeoWandersleb | 9 months ago (raw) | root | parent | reply | flag +3 
 Right now, the nip repo is just a collection of documents and people try to nip this and that and it's hard to know when something relevant happens. As a client dev you would not only want to know of breaking changes but also about new features relevant to your client. I certainly would love to have a chronological list of changes to catch up on but it shouldn't be a burden to those defining the standard so ... volunteers? Where is the @nipReporter?