Time Nick Message 03:49 Devy @rubenwardy, have time to answer a quick question? 03:49 Devy It's about a PR on Github 03:51 Devy Oh, dang he's from UK. He is sleeping... Anyone else here live and can answer a question about a PR? 11:11 Krock will merge #7443 in 10 minutes 11:12 ShadowBot https://github.com/minetest/minetest/issues/7443 -- Make os.tempfolder work correctly for MinGW and MSVC by nOOb3167 11:21 Krock merging.. 11:50 nerzhul ty Krock for the review 11:50 nerzhul i answer to your question 11:54 Krock I see, ok. 16:15 Wuzzy Please someone look at #7019. 16:15 ShadowBot https://github.com/minetest/minetest/issues/7019 -- Colorize command parameters and privilege names by Wuzzy2 16:26 Krock it's on the developer meeting list for some weeks now but yet nothing happened :3 16:35 paramat no response yet from lhof, nore or ShadowNinja (however the last 2 are long inactive). looking at the opinions so far https://github.com/minetest/minetest/issues/6073#issuecomment-396597034 shall we now officially choose semver 5.0.0? 16:36 nore Either one is fine with me 16:46 paramat thanks for the feedback 16:46 Krock nice. All what's needed is a final commit to since the majority accepts it 16:46 Krock *to change it 16:47 Krock Wuzzy, added two further comments. Using Lua's expressions in gsub your changes could be minimized a lot 16:48 Wuzzy paramat: so SemVer is now coming, but you skip 4 major versions? XD 16:50 Wuzzy Krock: i dont see your 2 further comments at all 16:50 Krock Ctrl + F5, maybe? 16:51 Wuzzy still nothing 16:51 Krock SemVer does not state where to begin with versioning for software that is already "used in production" 16:52 Wuzzy so SemVer it is, then? 16:52 Krock Wuzzy, https://github.com/minetest/minetest/pull/7019#discussion_r195155241 and the other is on the very bottom 16:52 Wuzzy i wont start a holy war about 5.0.0 vs other version :) 16:52 Wuzzy that's not you 16:53 Krock ok, if you say so.. 16:54 Wuzzy you dont appear on discussion at all. weird 16:54 Wuzzy wtf? did i just broke the Internet? 17:06 paramat there is one point in semver spec i disagree with: incrementing minor every time there is a new API feature, that would be silly :) 17:23 Wuzzy but thats how it works 17:23 Wuzzy basically semver is like current version, but everything shifts 1 place to the left 17:24 Wuzzy currently we have .. 17:24 Wuzzy there is no patch place 17:24 Wuzzy SemVer is .. 17:24 Wuzzy it would not be silly imo 17:25 Krock paramat, we'll update it on each release so that's not a problem 17:25 Wuzzy ok sometimes we have a patch place when we add a 4th place like 0.4.17.1 17:27 Wuzzy basically we would go from ULTRA.MAJOR.MINOR.PATCH to MAJOR.MINOR.PATCH. The ULTRA is dropped. thats not silly at all 17:29 Wuzzy so as i understood the future versions be like... 17:29 Wuzzy 0.4.17.1 17:29 Wuzzy 5.0.0 17:29 Wuzzy (new features) 17:29 Wuzzy 5.1.0 17:29 Wuzzy (moar features) 17:29 Wuzzy 5.2.0 17:29 Wuzzy (bugfixes only) 17:29 Wuzzy 5.2.1 17:29 Wuzzy (incompatible patch) 17:29 Wuzzy 6.0.0 17:29 Wuzzy and so on 17:31 Krock thanks. we understood it just fine at the begining 17:52 nerzhul Krock: #7437 fixed 17:52 ShadowBot https://github.com/minetest/minetest/issues/7437 -- Server: move shutdown parts to a specific shutdown state object by nerzhul 18:09 Krock nerzhul, any comments for #7357? The chat system is yet not ready to include the change you suggested 18:09 ShadowBot https://github.com/minetest/minetest/issues/7357 -- Make the server status message customizable by SmallJoker 18:10 Krock i.e. the Lua API functions do not offer that functionality yet 18:32 nerzhul Krock: the system chat message type is not sufficient ? 18:33 sfan5 when discussing the semver switch, do we want (need?) to differentiate between "just dropping the leading zero" and "fully switching to semver"? 18:33 sfan5 lookint at Wuzzy's comment on the issue, it looks like we'd have to decide what to do with -dev too 18:34 sfan5 along with following every other rule of semver which I haven't personally read 18:34 Wuzzy lol 18:35 Krock nerzhul, didn't mean to say that. it's sufficient - for C++. But it's yet not available to Lua 18:35 Krock also builtin and administrative mods should be able to send system chat messages 18:37 Krock sfan5, not much of a problem if we automatically attach the git SHA to our version (which already happens on Linux) 18:37 sfan5 not a problem no 18:38 sfan5 i'm just asking whether we want to drop the -dev suffix (switch to semver with all its rules) 18:39 Krock how would a in-development version look like of we would drop the -dev suffix? 18:39 Krock 5.0.0-githash ? 18:39 sfan5 yes 18:40 sfan5 see https://github.com/minetest/minetest/issues/6073#issuecomment-397036626 18:42 Krock it could also be 5.0.0-dev+githash 18:43 Krock s/+/-/ 18:48 sfan5 does that follow the semver rules? 18:49 Krock Wuzzy ^? 18:51 Wuzzy hmmm 18:51 Wuzzy first, read the document :) 18:51 Wuzzy second 18:51 Wuzzy anything of the form "X.Y.Z-word" is called a pre-release version 18:51 Wuzzy e.g. 1.2.3-alpha is a prerelease version to 1.2.3 18:51 Wuzzy you can use any words you like after the hyphen 18:52 Wuzzy 1.2.3-dev would be just a pre-release to 1.2.3 18:52 sfan5 right, then you would append the githas after a + 18:52 Krock so is -dev. if it must point to a specific change, then attaching the githash shouldn't be problem 18:52 Wuzzy note you can hve multiple pre-release versions 18:52 Wuzzy like -dev, -beta, -alpha, or -whatever 18:52 Wuzzy in that case, alphabetical order determines precedence 18:53 Wuzzy sorry sfan5, sadly thats not how it works 18:53 Wuzzy 1.2.3-dev has to refer to ONE specific released version 18:53 Wuzzy the +githash does not actually change the version 18:53 Krock [0-9A-Za-z-] are allowed so 1.2.3-dev-githash is allowed there 18:53 paramat i'd rather not strictly follow semver, a 'dev' suffix is fine 18:53 sfan5 right 18:53 Wuzzy ... 18:53 VanessaE so long as it has the githash 18:54 VanessaE or a date or build number or something 18:54 paramat i suggest loosely following semver but adding in our way of doing stuff 18:54 Wuzzy 1.2.3-dev.githash would be allowed 18:54 Wuzzy no wait 18:54 Wuzzy hmmmmm no sorry 18:54 Wuzzy it wouldnt work that way either because that is also subject to sorting 18:55 Wuzzy 1.2.3-dev-000000 would be before 1.2.3-dev-123e4f 18:55 Krock if [0-9A-Za-z-] are for identifiers and identifiers must point to an unique version (commit), then our current scheme must be acceptable 18:55 Krock and how would that be sorted? alphabetically? seems a bit weird 18:55 paramat Wuzzy you misunderstood what i was referring to as silly :) 18:57 Wuzzy the thing is, we have to realize that 1.2.3-dev is more like a convention, not an actual version. even under current rules 18:58 sfan5 I would rather keep our current convention and not follow semver by the letter 18:58 Wuzzy 1.2.3-dev is actually a shorthand for "this any commit that is before 1.2.3, but after the version that preceded version 1.2.3". 18:59 Krock at least keep the significant numbers right, the other is not too important because we're not a library where projects depend on 18:59 Wuzzy ... 18:59 Wuzzy Lua API?! 19:02 Wuzzy We could say, "For RELEASED versions of Minetest, we use SemVer. For in-development versions, we have a special convention of the form X.Y.Z-dev which has a special meaning which is defined as follows: Bla Bla Bla ..." 19:02 sfan5 that would be stupid 19:03 sfan5 either you fully commit or you don't 19:03 Wuzzy meh i am still not happy if we have to add any exceptions and modifications to SemVer. this sucks. :( kind of defeats the whole point of SemVer 19:03 Wuzzy so... SemVer is rejected then? 19:05 Wuzzy i never liked the -dev convention anyway. its weird in that its not a real version number. plus there was this confusion about whether -dev is the version before or after a released version 19:05 Wuzzy maybe in minetset in-dev versions cuold be refered to by their commit ID, then add "leading to X.Y.Z" 19:05 paramat might be best to not say we're following semver (as some may interpret that as strict semver, causing silly discussions like this) but our own system that is similar 19:06 sfan5 nothing is rejected, that's just my opinion 19:06 Wuzzy e.g. Minetest, dev version commit 0123456789abdef leading to 0.5.0 19:06 Wuzzy or something with less words 19:07 Wuzzy Or rename Minetest to Minetest-dev whenever its a non-released version. XD 19:07 paramat anyway does semver have to mean ultra-strict follow every rule, or is it more of a guideline? 19:08 sfan5 paramat: if we're not following semver, i'd rather state "we're dropping the leading zero" rather than "we follow semver but with lots of exceptions" 19:08 Krock released version: MAJOR.MINOR.PATCH, rolling release build: MAJOR.MINOR.PATCH-dev-GITHASH. works for me. 19:08 Wuzzy semver is strict, otherwise its pointless 19:08 Wuzzy the thing is, this -dev is really an invention in minetest. i never seen something like this before 19:09 paramat sfan5 i agree, less baggage 19:09 Wuzzy SemVer works great and can be followed easily for releases. it is not a versioning scheme for every commit ever. 19:09 Wuzzy minetest versioning currently seems to be a strange mix of release versioning and versioning every commit ever. 19:10 Wuzzy if we hadnt this -dev, adopting SemVer would be trivial 19:10 paramat if semver has to be strict to the letter it's surprising anyone uses it :) 19:10 Wuzzy well you cant say you follow semver if you break some rules. if it would be nonstrict than anyone cuold just claim anything. 19:11 Wuzzy this complaint just does not make sense 19:11 Wuzzy if you code C++ you also just can't be "flexible" about the source code 19:11 paramat anyway, seems worth avoiding the semver word if it means we can avoid all this silly discussion ;) 19:11 Wuzzy have you read SemVer definition? 19:11 paramat yes 19:12 Wuzzy I opine that SemVer does have many good and sensible ideas. 19:12 Wuzzy like the rule that one version = exactly one release 19:12 paramat versioning can be more flexible than code, it's human-parsed 19:13 Wuzzy i have seen far too often that programmers did not change the version number but tried to sneak a different code base in... 19:13 Wuzzy this practicse is really annoying 19:13 Wuzzy SemVer can be human-parsed, too. but also machine parsed 19:14 Wuzzy really the only problem which might hold minetest back is this -dev thing 19:14 Wuzzy if we wouldnt have -dev, then semver would be possible to follow to the letter 19:15 paramat anyway, we will increment 'minor' per release, not per API feature, so we can't do strict semver 19:15 Wuzzy this is perfectly legal 19:15 sfan5 to be honest I don't really see much of a problem with our current version scheme, which is why I've been neutral to this from the beginning 19:17 Wuzzy i never said current version scheme is a problem 19:17 paramat spec: "Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated." can't do either of those 19:17 Wuzzy why not 19:17 Wuzzy give me an example 19:18 paramat ugh 19:18 Wuzzy paramat you also have " It MAY be incremented if substantial new functionality or improvements are introduced within the private code" 19:18 Wuzzy so... normal, non-api features. 19:18 Wuzzy i dont see the problem 19:19 Wuzzy so most non-compat breaking releases would increase MINOR 19:19 Wuzzy srsly, minor is really not the problem here 19:20 paramat because minor would be incremented every 4 commits or so. we will increment it on a release as currently 19:20 Wuzzy of course not. 19:20 Wuzzy all these rules apply only when you actually do a release 19:20 Wuzzy semver does not dictate WHEN to make release 19:21 Wuzzy could be every 4 commits, or every 40,000. it doesnt matter 19:21 Wuzzy the versioning just indicate the changes between two releases 19:21 Wuzzy e.g. 1.0.0 → 1.1.0 means that some features have been addeed in a non-breaking way 19:23 Wuzzy when i think about it, this -dev convention is a but problematic 19:23 Wuzzy you cant really have branching 19:23 Wuzzy i mean what were the dev versions called before 0.4.17.1 came out? 19:23 Wuzzy i believe 0.5.0-dev, right? 19:24 Wuzzy you cant really predict what will be the next version immediately after a fresh release. might be major. might be minor. or even just patch 19:24 Krock 0.4.15-dev became 0.4.16 19:25 Wuzzy thats not the point, also this is the old scheme 19:25 Wuzzy -dev forces you to predict whether your next release is major, minor or patch. 19:25 Wuzzy if you release 1.0.0, then what will be the -dev versino after that? 19:25 Wuzzy 2.0.0-dev? 1.1.0-dev? 1.0.1-dev? 19:25 Krock depends on the state of development 19:25 Krock it'll be pushed upwards the more changes were made 19:26 Wuzzy that seems very confusing 19:26 Krock so all of them would be build during development, until the final version is reached 19:26 Krock s/build/built/ 19:27 Wuzzy lol are you suggesting you wuold have all 3 of them? sounds overkill 19:27 Wuzzy i think the way how "-dev" is defined is a bit strange and flawed 19:28 Wuzzy -dev versions are fundamentally different than point releases, even by the versioning scheme 19:28 Wuzzy point releases refer to one specific commit and are unambigious 19:28 sfan5 -dev version are not releases, they are a state of development 19:28 Wuzzy -dev releases refer to a huge range of commits 19:29 Wuzzy exactly 19:29 sfan5 is that a problem? 19:29 sfan5 it's true that no other projects do this, but I don't see a problem with this 19:29 Wuzzy SemVer can handle point releases, but -dev is incompatible with SemVer by design 19:30 Wuzzy we might also say "fuck it" and consider the "-dev notation" to be "outside of versions". 19:30 Wuzzy that sucks because it still looks like a real version :( 19:30 Wuzzy sfan5: its a problem if the goal is to adopt SemVer. if the goal is to say "fuck it" then its not a problem, no. ;) 19:31 Krock partial "fuck it". not too bad. 19:32 Wuzzy or maybe we could change -dev notation in a way that makes it not look like a SemVer. like 1.2.3::githash 19:33 Wuzzy ok that notation looks ugly. but you get my point 19:41 paramat oh, maybe i misunderstood .. 19:42 paramat sorry 19:42 paramat but still, i don't support strict semver 19:42 Wuzzy why not 19:43 Wuzzy note there can only be "strict" semver or no semver. there is nothing in-between 19:44 Krock why not 19:44 Wuzzy define a middle ground 19:45 Wuzzy just for the sake of argument 19:45 Krock in between that MAJOR.MINOR.PATCH alone (and only these) are stable versions 19:46 rubenwardy omg, chat 19:46 Krock and -dev refers to in-development builds which are compatible to these according to semver 19:46 Krock rubenwardy, welcome to the party 19:46 paramat yes looks like it has to be strict "you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management." 19:46 rubenwardy there is one point in semver spec i disagree with: incrementing minor every time there is a new API feature, that would be silly :) 19:46 paramat so i'm -1 for semver then. +1 for major.minor.patch 19:46 rubenwardy this isn't a thing 19:47 rubenwardy you implement MAJOR when you break things 19:47 rubenwardy MINOR when it's a feature release 19:47 rubenwardy PATCH when it's a bug fix release 19:47 rubenwardy simple 19:47 Wuzzy Krock: you just invented your own versioning scheme, which has resemblence to SemVer, but is not SemVer 19:47 Wuzzy either you do SemVer or you don't. it's simple 19:47 Krock Wuzzy, hence "in between" 19:47 Wuzzy your invention clearly falls in the "not SemVer" category 19:47 paramat rubenwardy yes, i misunderstood :3 19:48 Wuzzy its a binary. its like you can't be 50% pregnant :) 19:48 Wuzzy rubenwardy: paramat: already retracted that claim 19:48 rubenwardy I'm still catching up 19:49 rubenwardy also, saying A.B.C-dev to refer to a branch is fine 19:49 Wuzzy you can increase MINOR when you add non-API features as well 19:49 rubenwardy and I don't think that really matters either way 19:50 Wuzzy A.B.C-dev looks like a version, but is something entirely different. i think even many mt devs and contribs think of them as versions 19:50 Wuzzy the real question is: "how do we refer to a in-dev state in a non-confusing way?" 19:51 Wuzzy this question is actually a different beast than whether we use SemVer or not 19:55 paramat almost of the specs make good sense, but there will be some rules where we prefer to do things our own way. there is no practical reason to use strict semver, it's just a suggested scheme :) 19:55 Wuzzy what rule in SemVer do you dislike? 19:56 rubenwardy this kinda feels predantic to me 19:56 Wuzzy ? 19:57 Wuzzy you literally code in a language which is pedantic by nature :) 19:57 rubenwardy just do +hash instead of -dev 19:57 rubenwardy done 19:57 rubenwardy who cares 19:57 sfan5 Wuzzy: note that we don't use the -pedantic compiler flag 19:57 sfan5 ;) 19:58 rubenwardy or -hash 19:58 rubenwardy but whatever 19:58 Wuzzy okay, but then you're not using SemVer but your own rules. 19:58 nerzhul merging #7437 19:58 rubenwardy or keep it as -dev, there's more important things 19:58 ShadowBot https://github.com/minetest/minetest/issues/7437 -- Server: move shutdown parts to a specific shutdown state object by nerzhul 19:58 nerzhul ty Krock 19:58 Krock np 19:58 Wuzzy i believe the current scheme is X.Y.Z-dev-githash? 19:58 rubenwardy the most important part of semver is MMP 19:59 Wuzzy with -githash being optional 19:59 rubenwardy well, whatever 19:59 Krock Wuzzy, 0.5.0-dev-debug-7113596c-dirty 19:59 Krock example of our system right now, with all stuff around 19:59 rubenwardy I suggest doing this in two parts 19:59 Wuzzy now my brain just exploded 19:59 Krock >:D 19:59 rubenwardy 1. changing to MMP and using semver increment rules 2. changing -dev 20:00 Wuzzy that sounds sensible 20:00 Wuzzy would be nice to just write down how minetest versions work :P 20:01 Wuzzy the definition of -dev makes my brain go bye bye 20:02 rubenwardy it should be treated as a vague range referring to any commit between two versions 20:02 rubenwardy not a specific commit 20:02 Wuzzy no i mean the -dev-debug-??????-dirty part of the definition :) 20:02 Wuzzy dirty lol 20:03 Wuzzy can a dev version ever be clean? 20:03 rubenwardy heh 20:03 rubenwardy you know what dirty means right? 20:03 rubenwardy yes it can be clean 20:03 rubenwardy if there's no unstashed changes 20:04 rubenwardy wait, that's the case right? 20:04 rubenwardy *uncommitted 20:05 Wuzzy so if clean, the -dirty is dropped? 20:05 rubenwardy that's how I thought it worked 20:05 Wuzzy and the -debug- thing... does this refer to CMAKE flag? debug vs release? 20:05 Krock yes 20:06 Wuzzy this sound an awful lot like build metadata 20:06 Krock yes to both of Wuzzy's questions 20:07 p_gimeno there's a simple solution to do SemVer for dev releases too 20:07 p_gimeno switch to HG 20:07 * p_gimeno runs 20:08 Wuzzy ??? 20:08 Wuzzy how should that help? 20:08 p_gimeno HG provides a sequential commit number 20:09 Wuzzy yes but thats only local, so its unsuited for versioning 20:09 Wuzzy as soon you do branching, all hell breaks loose 20:09 Wuzzy the sequential numbers are merely used as a shorthand so you can do less typin when using the hg program 20:10 Wuzzy they should not be treated as unique ids 20:10 p_gimeno there's a canonical numbering though, the one in the main repo, and branching is irrelevant 20:10 Wuzzy at least not globally 20:11 p_gimeno http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/18 - guess what the 4th number is :) 20:11 p_gimeno I've seen the -dev suffix in several projects, MT is not really the only one 20:12 rubenwardy how about Donesday clock messaging? 20:12 p_gimeno I think that the solution to the conundrum is as simple as "we don't follow semver for pre-releases, only for releases" 20:12 rubenwardy versions a labelled like a clock based on how close they are to finishing 20:13 rubenwardy 03:30 20:13 rubenwardy 13:23 20:13 rubenwardy 23:58 (almost done!) 20:13 rubenwardy wouldn't end up with duplicate versions 20:13 rubenwardy totally logical 20:13 rubenwardy could label each commit too 20:13 Krock rubenwardy, please... 20:14 p_gimeno 23:59:59.9999993... 23:59:59.9999994... 20:14 rubenwardy exactly 20:14 paramat :P 20:14 rubenwardy there's infinite amount of precision 20:14 rubenwardy up to the planck time, that is 20:15 Wuzzy p_gimeno: -dev is not a pre-release 20:18 p_gimeno Wuzzy: same difference I guess? "we only follow semver for released versions, not for rolling releases" 20:19 Wuzzy we dont do rolling releases