On Fri, May 25, 2012 at 10:37 AM, Tomas Guisasola Gorham <[email protected]> wrote: > Hi Thijs > > > On Fri, 25 May 2012, Thijs Schreijer wrote: > >>> From: Tomas Guisasola Gorham [mailto:[email protected]] >>> Sent: vrijdag 25 mei 2012 1:45 >>> To: [email protected] >>> Subject: Re: [Luarocks-developers] [ANN] LuaRocks 2.0.9-rc1 >>> >>> Hi Hisham >>> >>> On Thu, 24 May 2012, Hisham wrote: >>>> >>>> I'm calling this a minor version because the release adds new >>> >>> features >>>> >>>> to the command-line tools but shouldn't add any changes to the >>>> rockspec format. >>> >>> I think we use the third digit to bug fixes; adding new features >>> should change the second digit. It would be reasonable to change the >>> first digit when the rockspec format changes... Just my opinion. >> >> >> 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/ ------------------------------------------------------------------------------ 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
