6 ms·

It's actually been done (IMO) and done for several decades. In Manufacturing, they have the 'Form, Fit or Function' "Rule" [0]. In essence, your have only a t

by oso2k 10y ago

It's actually been done (IMO) and done for several decades. In Manufacturing, they have the 'Form, Fit or Function' "Rule" [0]. In essence, your have only a two segment part number, and the 2nd part is considered non-essential, and only for deep traceability. For software, I would apply the rule as such: 1) merge the major and minor segments, and the revision segment becomes equivalent, 2) then you follow the Form, Fit or Function rule and apply it to the core product, programs, and APIs. [0] http://www.arenasolutions.com/resources/articles/form-fit-function/ http://www.arenasolutions.com/resources/articles/form-fit-fu... [1] http://www.buyplm.com/plm-good-practice/plm-software-part-revision-form-fit-function.aspx http://www.buyplm.com/plm-good-practice/plm-software-part-re...

Klathmon 10y ago
Would you be able to expand on this a bit? I'm having trouble trying to figure out the analogy to the software world. You are saying basically have just `major.revision` correct? Would this be similar to how Chrome does their versioning?
- oso2k 10y ago
  In short, yes. See my other response here [0]. [0] https://news.ycombinator.com/item?id=12792868 https://news.ycombinator.com/item?id=12792868
jharger 10y ago
I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries I've used (FFF works here) and everything is running smoothly. However, a large customer requests a new feature, and I see that library X has a new version that has new features that will support development for the new customer feature. With semver, I can see that this new version is, say, 2.3.0. If I was using 2.2.x, I have at least some assurance that the API I was using before hasn't changed, so the amount of work to upgrade is likely limited to implementing new features, and not converting and re-testing older code. However, with the FFF rule, it seems that the new version would change (due to form/fit (api?] or function changing), and all I know is that this version is new, and I have no indication how much work it would be to upgrade, other than assume the worst case that existing APIs have changed. I could see why the manufacturing methods might make sense, especially in certified software... but in the wild west of web development, I have a feeling it would never catch on.
- oso2k 10y ago
  FFF would say that you release a new part number. But, it does not say how you name your part. So, you can essentially use a SemVer technique to indicate the same family of functionality with some sort of indication non-compatibility. Part Name: MY SW 2.0 Predecessor Part Number: 150000-0001 Part Number: 200000-0001 And you have Part Name: MY SW 2.0-IBM Predecessor Part Number: 200000-0001 Part Number: 200001-0001 Say your added features to your IBM branch caused some regression. So now you have a second build that is compatible but required a bug fix. Now you have Part Name: MY SW 2.0-IBM Predecessor Part Number: 200001-0001 Part Number: 200001-0002 The biggest thing you should take away is that Enterprise Manufacturing and Inventory systems do not try to stuff all the knowledge about a product history into a single field, as SemVer attempts to.

by oso2k 10y ago

Klathmon 10y ago

Would you be able to expand on this a bit? I'm having trouble trying to figure out the analogy to the software world. You are saying basically have just `major.revision` correct? Would this be similar to how Chrome does their versioning?

oso2k 10y ago
In short, yes. See my other response here [0]. [0] https://news.ycombinator.com/item?id=12792868 https://news.ycombinator.com/item?id=12792868

jharger 10y ago

I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries I've used (FFF works here) and everything is running smoothly. However, a large customer requests a new feature, and I see that library X has a new version that has new features that will support development for the new customer feature. With semver, I can see that this new version is, say, 2.3.0. If I was using 2.2.x, I have at least some assurance that the API I was using before hasn't changed, so the amount of work to upgrade is likely limited to implementing new features, and not converting and re-testing older code. However, with the FFF rule, it seems that the new version would change (due to form/fit (api?] or function changing), and all I know is that this version is new, and I have no indication how much work it would be to upgrade, other than assume the worst case that existing APIs have changed. I could see why the manufacturing methods might make sense, especially in certified software... but in the wild west of web development, I have a feeling it would never catch on.

oso2k 10y ago
FFF would say that you release a new part number. But, it does not say how you name your part. So, you can essentially use a SemVer technique to indicate the same family of functionality with some sort of indication non-compatibility. Part Name: MY SW 2.0 Predecessor Part Number: 150000-0001 Part Number: 200000-0001 And you have Part Name: MY SW 2.0-IBM Predecessor Part Number: 200000-0001 Part Number: 200001-0001 Say your added features to your IBM branch caused some regression. So now you have a second build that is compatible but required a bug fix. Now you have Part Name: MY SW 2.0-IBM Predecessor Part Number: 200001-0001 Part Number: 200001-0002 The biggest thing you should take away is that Enterprise Manufacturing and Inventory systems do not try to stuff all the knowledge about a product history into a single field, as SemVer attempts to.