| Time |
Nick |
Message |
| 00:19 |
|
proller joined #minetest-dev |
| 00:21 |
|
kaisser joined #minetest-dev |
| 00:23 |
|
proller joined #minetest-dev |
| 00:26 |
|
proller joined #minetest-dev |
| 00:28 |
|
proller joined #minetest-dev |
| 00:32 |
|
proller joined #minetest-dev |
| 00:34 |
|
proller joined #minetest-dev |
| 00:38 |
|
proller joined #minetest-dev |
| 00:40 |
|
proller joined #minetest-dev |
| 00:42 |
|
proller joined #minetest-dev |
| 00:50 |
|
ANAND joined #minetest-dev |
| 00:50 |
|
proller joined #minetest-dev |
| 00:57 |
|
proller joined #minetest-dev |
| 00:59 |
|
proller joined #minetest-dev |
| 01:01 |
|
proller joined #minetest-dev |
| 01:05 |
|
proller joined #minetest-dev |
| 01:17 |
|
proller joined #minetest-dev |
| 01:18 |
|
proller joined #minetest-dev |
| 01:18 |
|
proller joined #minetest-dev |
| 01:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 01:21 |
|
proller joined #minetest-dev |
| 01:24 |
|
proller joined #minetest-dev |
| 01:26 |
|
proller joined #minetest-dev |
| 01:28 |
|
proller joined #minetest-dev |
| 01:48 |
|
proller joined #minetest-dev |
| 01:56 |
|
proller joined #minetest-dev |
| 01:59 |
|
proller joined #minetest-dev |
| 02:01 |
|
proller joined #minetest-dev |
| 02:04 |
|
proller joined #minetest-dev |
| 02:14 |
|
proller joined #minetest-dev |
| 02:15 |
|
proller joined #minetest-dev |
| 02:18 |
|
DI3HARD139 joined #minetest-dev |
| 02:19 |
|
proller joined #minetest-dev |
| 02:26 |
|
proller joined #minetest-dev |
| 02:32 |
|
proller joined #minetest-dev |
| 02:33 |
|
proller joined #minetest-dev |
| 02:34 |
|
AndroBuilder joined #minetest-dev |
| 02:36 |
|
ANAND joined #minetest-dev |
| 02:42 |
|
proller joined #minetest-dev |
| 02:44 |
|
proller joined #minetest-dev |
| 02:45 |
|
proller joined #minetest-dev |
| 02:50 |
|
proller joined #minetest-dev |
| 02:50 |
|
proller joined #minetest-dev |
| 02:53 |
|
proller joined #minetest-dev |
| 02:55 |
|
proller joined #minetest-dev |
| 03:02 |
|
proller joined #minetest-dev |
| 03:04 |
|
proller joined #minetest-dev |
| 03:06 |
|
proller joined #minetest-dev |
| 03:19 |
|
proller joined #minetest-dev |
| 03:22 |
|
proller joined #minetest-dev |
| 03:24 |
|
proller joined #minetest-dev |
| 03:27 |
|
proller joined #minetest-dev |
| 03:30 |
|
proller joined #minetest-dev |
| 03:48 |
|
Devy joined #minetest-dev |
| 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? |
| 04:02 |
|
proller joined #minetest-dev |
| 04:09 |
|
proller joined #minetest-dev |
| 04:19 |
|
proller joined #minetest-dev |
| 04:20 |
|
proller joined #minetest-dev |
| 04:24 |
|
Devy left #minetest-dev |
| 04:24 |
|
proller joined #minetest-dev |
| 04:28 |
|
proller joined #minetest-dev |
| 04:44 |
|
proller joined #minetest-dev |
| 04:52 |
|
proller joined #minetest-dev |
| 04:53 |
|
proller joined #minetest-dev |
| 04:56 |
|
proller joined #minetest-dev |
| 05:01 |
|
proller joined #minetest-dev |
| 05:02 |
|
proller joined #minetest-dev |
| 05:07 |
|
proller joined #minetest-dev |
| 05:32 |
|
thoughtjigs joined #minetest-dev |
| 05:38 |
|
proller joined #minetest-dev |
| 05:44 |
|
proller joined #minetest-dev |
| 05:53 |
|
proller joined #minetest-dev |
| 06:03 |
|
ssieb joined #minetest-dev |
| 06:04 |
|
proller joined #minetest-dev |
| 06:04 |
|
proller joined #minetest-dev |
| 06:09 |
|
proller joined #minetest-dev |
| 06:09 |
|
proller joined #minetest-dev |
| 06:27 |
|
proller joined #minetest-dev |
| 06:31 |
|
proller joined #minetest-dev |
| 06:35 |
|
proller joined #minetest-dev |
| 06:37 |
|
proller joined #minetest-dev |
| 06:41 |
|
proller joined #minetest-dev |
| 06:52 |
|
proller joined #minetest-dev |
| 07:17 |
|
proller joined #minetest-dev |
| 07:34 |
|
behalebabo joined #minetest-dev |
| 07:34 |
|
fireglow joined #minetest-dev |
| 07:51 |
|
proller joined #minetest-dev |
| 07:52 |
|
proller joined #minetest-dev |
| 07:56 |
|
proller joined #minetest-dev |
| 08:01 |
|
AntumDeluge joined #minetest-dev |
| 08:02 |
|
proller joined #minetest-dev |
| 08:03 |
|
proller joined #minetest-dev |
| 08:06 |
|
proller joined #minetest-dev |
| 08:10 |
|
troller joined #minetest-dev |
| 08:17 |
|
proller joined #minetest-dev |
| 08:20 |
|
proller joined #minetest-dev |
| 08:21 |
|
proller joined #minetest-dev |
| 08:24 |
|
proller joined #minetest-dev |
| 08:33 |
|
proller joined #minetest-dev |
| 08:34 |
|
proller joined #minetest-dev |
| 08:46 |
|
proller joined #minetest-dev |
| 08:51 |
|
proller joined #minetest-dev |
| 08:53 |
|
proller joined #minetest-dev |
| 08:59 |
|
proller joined #minetest-dev |
| 09:01 |
|
proller joined #minetest-dev |
| 09:05 |
|
troller joined #minetest-dev |
| 09:11 |
|
Calinou joined #minetest-dev |
| 09:14 |
|
proller joined #minetest-dev |
| 09:17 |
|
troller joined #minetest-dev |
| 09:17 |
|
Fixer joined #minetest-dev |
| 10:08 |
|
paramat joined #minetest-dev |
| 10:29 |
|
lumberJ joined #minetest-dev |
| 10:40 |
|
clavi joined #minetest-dev |
| 10:42 |
|
Beton joined #minetest-dev |
| 10:45 |
|
opal joined #minetest-dev |
| 10:51 |
|
Krock joined #minetest-dev |
| 11:08 |
|
entuland joined #minetest-dev |
| 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. |
| 12:27 |
|
Raven262 joined #minetest-dev |
| 12:52 |
|
paramat joined #minetest-dev |
| 13:34 |
|
antims joined #minetest-dev |
| 13:54 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Minetest 0.4.17.1 released! Chit-chat goes to #minetest. http://irc.minetest.net/minetest-dev/ http://dev.minetest.net/ |
| 13:56 |
|
entuland joined #minetest-dev |
| 15:13 |
|
Wuzzy joined #minetest-dev |
| 15:14 |
|
Lunatrius joined #minetest-dev |
| 15:31 |
|
AndroBuilder joined #minetest-dev |
| 15:37 |
|
lisac joined #minetest-dev |
| 15:48 |
|
Gael-de-Sailly joined #minetest-dev |
| 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:20 |
|
AndroBuilder joined #minetest-dev |
| 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? |
| 16:59 |
|
Lunatrius joined #minetest-dev |
| 17:02 |
|
AndroBuilder joined #minetest-dev |
| 17:05 |
|
AndroBuilder joined #minetest-dev |
| 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:16 |
|
ANAND joined #minetest-dev |
| 17:17 |
|
ensonic joined #minetest-dev |
| 17:21 |
|
Tmanyo joined #minetest-dev |
| 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 <ULTRA MAJOR>.<MAJOR>.<MINOR> |
| 17:24 |
Wuzzy |
there is no patch place |
| 17:24 |
Wuzzy |
SemVer is <MAJOR>.<MINOR>.<PATCH> |
| 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:39 |
|
ssieb joined #minetest-dev |
| 17:47 |
|
entuland joined #minetest-dev |
| 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:05 |
|
paramat joined #minetest-dev |
| 18:06 |
|
Darcidride joined #minetest-dev |
| 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 |
|
Player-2 joined #minetest-dev |
| 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 |
|
ensonic joined #minetest-dev |
| 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 |
<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 :) |
| 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 |
|
proller__ joined #minetest-dev |
| 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:10 |
|
BillyS joined #minetest-dev |
| 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 |
| 20:35 |
|
thoughtjigs left #minetest-dev |
| 20:35 |
|
thoughtjigs joined #minetest-dev |
| 21:13 |
|
paramat joined #minetest-dev |
| 21:45 |
|
proller__ joined #minetest-dev |
| 21:58 |
|
entuland joined #minetest-dev |
| 22:02 |
|
Fixer_ joined #minetest-dev |
| 22:55 |
|
pipo joined #minetest-dev |
| 22:57 |
|
pipo left #minetest-dev |
| 23:27 |
|
jcalve joined #minetest-dev |
| 23:35 |
|
Lunatrius joined #minetest-dev |
