> >> See http://semver.org/ > > Thanks for the link. Interesting initiative; I just posted a feedback > message on their issues page. > > https://github.com/mojombo/semver/issues/27 > > [[ > Side comment: The SemVer spec is interesting (I've seen that same idea > stated in other forms before) but I don't think one solution fits all > kinds of projects and development models (e.g., for a distro, the > Ubuntu year.month spec works great). Given that, in these "days of > Github", lots of people don't even bother to make proper releases > anymore, sometimes I'm just happy to see _any_ kind of version number > packaged (or at least tagged in repositories) [and yes, I noticed the > spec is written by one of the founders of Github]. > ]] > > > You haven't said, but I think you agree with me, don't you? > > In particular, the points 7 and 8 define a "patch version" as > a > > bug fix which increments the third digit, and a "minor version" as > the > > introduction of backwards campatible new features, which increments > the > > second digit... > > Fair points. In part, I think my confusion about versioning stems from > having two levels of compatibility to take care: rockspec > compatibility and command-line tool compatibility (and I'm working on > a branch that will add a LuaRocks API, so that will be a third line of > compatibility to take care of...). I have released some > strict-minor-bugfixes as "2.0.7.1" before, but it probably means I'm > misusing the "Y" number (unsurprisingly, it is still zero...) > > The fact is that I've been using version numbers more as a "marketing > tool", ie, as an indicator to users about how important the release > was ("x.y.z-rcN" releases say "looks ready to me, do you spot any > problems yet?", "x.y.z.W" releases say "it's the same thing, only with > the embarrassing bug fixed", "x.y.Z" releases say "development keeps > going!", "x.y.0" releases say "it's a big one fellas, pay attention > to this one!", and "X.0.0" releases say "forget about the past, > everyone move to the new world now!"). Not to mention users have their > own mental process they go through wrt version numbers (for example, > the classic "skip .0 releases, wait for things to stabilize"). > > Along that line of thinking, I was planning to use 2.1.0 when the API > gets added and/or when Lua 5.2 support is made official, and 3.0.0 > when the rockspec format changes. > > I'm not defending this vague and unscientific way of versioning or > claiming it is better, only explaining the sort-of-reasoning that went > behind it so far. :) I may rethink my practices. > > In the end, version numbers are a communication tool between > developers and users, so your feedback on how you could be better > served by it is most welcome. > > -- Hisham > http://hisham.hm/ >
The biggest issue I see with semver is the lack of support for development versions, Say you have 3.2, then a release candidate with a backward compatible change is released as 3.3.0-RC1, based on feedback the change is adjusted and changed to breaking, so it becomes 4.0-RC1, more comments all bad, so it is reverted to backward compatible with the 3.2, which is breaking again with 4.0-RC1, so we get 5.0-RC1. Gets messy quickly. (see issue 28; https://github.com/mojombo/semver/issues/28 ) Nevertheless, most important issue addressed is machine parsable versionnumbering with API compatibility information. I haven't seen anything else yet that is capable of doing so. Maybe not all things to all people, but certainly a big step forward, so I think it is worth endorsing. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
