On 19/06/2018 09:06, Norbert Hartl wrote: >> We can agree that there is no hard rule on versionning, do we? But I >> try to follow the following guidelines (delta my own interpretation >> that adds some subjectivity :P) >> - Major Version will change when we break backwards compatibility >> - Minor Version will change when new features are added >> - Otherwise, patch version will change. >> > There is only one hard rule for me and that is knowing about the risk to > take. So if we take the patch version it should only include important > bug fixes and nothing else. I would argue that only #864, #862, #858 and > #854 qualify for such a patch if at all. Not sure about #860 because the > title is not specific enough. > The point for me is that I want my project to rely on something like > 1.1.x because I don’t want anything to change that breaks my software. > And I can tell you that most developers underestimate the side-effects > of changes.
+1 to this. Only by introducing a new feature you MUST increment the minor version. >> Now, this is the kind of subjective topic that starts a flamewar, but >> I’d prefer to use my time on somewhat else ^^. > > You may not like to talk about these things but I do. And you should > listen. I have no use for an environment where people only care about > coding new cool stuff. > If it would be like this I would quit all my > pharo businesses, move to mainstream and would use pharo only for > hobbyist projects because that would be the level that can be met. I've used commercial Smalltalks before Pharo and VW for the last year, and although they're _ages_ behind some of the "modern" stuff in Pharo, they never compromise version semantics regarding these things. And if I give it a second thought I can point to other open-source non-smalltak big projects/libraries which are also cool but also follow strict versioning, and being bigger the cascade effect of changing artifacts semantics is way bigger. Please take this comment with a grain of salt, it's not a critic of all the work done in Iceberg or other projects, but it seems that these kind of "meta" (aka "PM", "strategy", or anything non-coding) discussions are avoided or muted, and they shouldn't. Regards, -- Esteban A. Maringolo
