3 ms·

Let's say that my application uses your library. Great! I code it, it works, and I release it for public consumption. It get popular, so that Ubuntu packages

by adekok 10y ago

Let's say that my application uses your library. Great! I code it, it works, and I release it for public consumption. It get popular, so that Ubuntu packages the application and your library. Millions of people use it. Now what happens when you release a new version of the library? All of the APIs with 710_foo become 720_foo. Which means that I have to rebuild my application to work with the library. I can't just link to the new version and get the bug fixes. Even worse, Ubuntu has to rebuild all applications which depend on your library. Every time you release a new version. This is why no one else puts version numbers into function / struct names. We rely on the C compiler to do type checks at compile time, and we rely on the linker to do symbol checks at run time. If no one else puts version numbers into function names, it should be a strong hint that you shouldn't do that, either. Similarly, 80-character symbols / macro names are just too complicated to use / remember. Pretty much no one else does this, either.

liblfds 10y ago
> I can't just link to the new version and get the bug fixes. I think this isn't quite right, by omitting the down side - that you will be getting the not just the bug fixes, but new bugs. It's not all roses! What has occurred between 710 and 720 is change. Ideally, hopefully, intended to be, positive change only. Bug fixes only. Improvements only. We all as software developers know there will in fact be new bugs introduced. Regression testings exists for that reason, and it is an imperfect method. So I guess what I'm saying is this : nothing, NOTHING, should change for a given application, without revalidation. Swapping a library version under the hood is by that view not good practise. By and large of course this is type of change is absolutely normal practise, because most of the time it seems to work, and it less costly and time consuming. (Really, it happens I think because humans are optimists and writing code is hard work and time consuming, so we involuntarily hope it's all fine and don't look hard for the bugs we've not found).
- adekok 10y ago
  > What has occurred between 710 and 720 is change. As you note, the changes should be minimal. i.e. the versions should be compatible. By changing the names, you are creating massive change, in order to bludgeon users of your library with the knowledge that there might be minor changes in it. This is counter-productive. > Swapping a library version under the hood is by that view not good practise. And re-naming everything is? Please, get over yourself. Your practice runs counter to 40 years of computer engineering. There are hundreds of thousands of Open Source projects which keep consistent names across minor releases. Either they're all wrong, every one of the millions of developers, or you are wrong. I think my review ends here. You're clearly in the camp of "I know better than everyone else".

by adekok 10y ago

liblfds 10y ago

> I can't just link to the new version and get the bug fixes. I think this isn't quite right, by omitting the down side - that you will be getting the not just the bug fixes, but new bugs. It's not all roses! What has occurred between 710 and 720 is change. Ideally, hopefully, intended to be, positive change only. Bug fixes only. Improvements only. We all as software developers know there will in fact be new bugs introduced. Regression testings exists for that reason, and it is an imperfect method. So I guess what I'm saying is this : nothing, NOTHING, should change for a given application, without revalidation. Swapping a library version under the hood is by that view not good practise. By and large of course this is type of change is absolutely normal practise, because most of the time it seems to work, and it less costly and time consuming. (Really, it happens I think because humans are optimists and writing code is hard work and time consuming, so we involuntarily hope it's all fine and don't look hard for the bugs we've not found).

adekok 10y ago
> What has occurred between 710 and 720 is change. As you note, the changes should be minimal. i.e. the versions should be compatible. By changing the names, you are creating massive change, in order to bludgeon users of your library with the knowledge that there might be minor changes in it. This is counter-productive. > Swapping a library version under the hood is by that view not good practise. And re-naming everything is? Please, get over yourself. Your practice runs counter to 40 years of computer engineering. There are hundreds of thousands of Open Source projects which keep consistent names across minor releases. Either they're all wrong, every one of the millions of developers, or you are wrong. I think my review ends here. You're clearly in the camp of "I know better than everyone else".