[00:34:34] https://github.com/NAVCoin/navcoin-core/pull/231 [00:39:56] @aguycalled can you kick off the build for the new rc branch 😃 [04:24:12] Actually scratch that, [04:24:19] we are moving to 4.3.0 [04:25:02] as this is a minor release as it is more than a patch with the open alias feature [04:25:12] (Mahor,Minor,Patch) [05:05:23] pr here 😃 [05:05:24] https://github.com/NAVCoin/navcoin-core/pull/232 [07:21:56] @aguycalled interesting. [07:22:00] https://medium.com/@snigirev.stepan/bls-signatures-better-than-schnorr-5a7fe30ea716 [08:10:05] @aguycalled can you kick off a build for the release? [08:10:32] yes, sorry was still going through the backlog of messages [08:11:23] haha... no hurry [08:11:37] just when you get to it my friend 😃 [08:12:06] building [08:12:24] wait [08:12:27] thanls [08:12:30] thanks [08:12:31] so 430 or 422 [08:12:31] 😃 [08:12:37] cool [08:12:52] ? [08:13:03] haha [08:13:12] sorry wrong window [08:13:15] 4.3.0 [08:13:55] I went back to the minor release convention [08:14:38] by that convention cold staking should be 5.0.0 and community fund 6.x.x [08:15:27] maybe, or maybe just reserved for hard forks [08:15:33] have nothing against, but breaks what weve done in the past [08:16:05] openalias do not introduce any change in the protocol [08:16:09] or consensus [08:16:14] is just client-side [08:16:52] craig and my thinking was that openalias should be a minor as its backwards compatible, but is a feature release [08:17:17] craig thinks cold staking and cfund should be a major [08:18:10] im not so sure as it is effectively backwards compatible [08:18:28] but this release is more than a patch [08:18:30] cfund acummulation is not backwards compatible [08:18:42] and we did 4.2.0 [08:18:42] ok then it is a major [08:18:55] as in 5.0 [08:18:58] ntp sync is quite a big change in the protocol [08:19:10] and was 4.2.0 [08:19:33] yea, it was still a minor release in my books [08:19:40] i think [08:19:50] we need to get this a bit tighter [08:20:07] but cfund + coldstaking should be 5.0.0 [08:20:29] ok, do you mean releasing them together [08:20:35] yea [08:20:36] or 5.0.0 and 6.0.0ç [08:20:48] yea... [08:21:01] but think we will wrap into 1 release [08:21:16] how are you going with cold staking testing [08:21:19] unless you want to get one out first? [08:21:20] do you need any help? [08:21:43] slowly, have been so slammed on everything else [08:22:00] so do you think we should break cold staking out [08:22:03] i think its better to do two separated releases [08:22:08] then cfund? [08:22:11] ok [08:22:29] then cold staking out first, as it is less risky [08:22:31] with the second being out like 1 month after the activation of the first soft fork [08:22:41] ? [08:22:42] cool [08:22:58] so if something was wrong we can isolate the issue [08:23:04] great [08:23:14] so coldstaking 5.0 [08:23:18] cfung 6.0 [08:23:56] open alias 4.3.0 [08:25:18] that fits well with [08:25:19] https://semver.org/ [08:25:27] ok [08:25:32] ill build 430 branch then [08:25:42] Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. [08:45:20] I always thought major version would be a complete overhaul like 3.x.x to 4.x.x [08:45:45] then minor versions were forks [08:46:06] and patches could introduce features as well but didn't require major changes [08:46:15] that's what it has been in the past right? [08:46:44] yea.. but we havent been doing in right and its a bit all over the place [08:47:01] so sometimes yes and sometimes no [08:47:33] from a code/blockchain perspective it majors are breaking changes [08:47:59] I see where you're coming from but I'm not sure if making such big jumps in the code versions could be confusing when the features introduced aren't immediately visible [08:48:06] this is hard forks, rewrites, and incompatible API changes [08:48:47] yea but we need to get on the train at some stage otherwise we will be in this limbo state forever [08:49:13] do other coins advance in steps this big as well? [08:50:35] it depends what they view their release versions [08:51:02] btc is still not 1.0 [08:51:45] other software like angular is at 6 after being at v2 at the beginning of the year [08:52:15] ethereum is advancing in 1.x steps as far as I can tell [08:52:36] and chrome is like at Version 67.0.3396.87 [08:52:45] hmm [08:53:43] Personally I think clarifying when to advance the version number with each kind of release is a good thing but I'm not sure if changing the "step size" in such a major way is understandable [08:53:57] I'm not a dev though, this is from a noob perspective [08:55:38] read this - https://semver.org/ let me know what you think [08:55:53] im open to all 😃 [08:56:53] maybe the intro then skip to the FAQ [08:57:43] I honestly think when we get to 6 we will hold for quite a while [08:58:15] as that is a lot of the protocol work complete [08:58:34] then we are on to layer 2 apps and support [08:59:38] maybe we should give each major nav release a name [09:01:05] makes it easier for people and then versioning is more for us and we can use it they way it should be [09:02:00] @aguycalled @prole what do you think about giving each major release of navcoin-core a name [09:03:04] they we can disconnect the versioning from the name and it will be easier for people to know what version they are on [09:03:34] im really bad finding new names, i leave this up to you guys [09:03:41] nothing against [09:04:26] ok might speak to the creative team and put a few naming theme forward to the community [09:09:09] sounds good too [09:09:15] I'll read the site at lunch [09:16:36] https://www.wordlab.com/name-generators/name-builder-name-generator/ [09:17:01] "HotThunder" [09:17:04] I'm down [09:17:07] 😂 [09:29:33] 😃 [13:12:47] named releases would be excellent... nice little article on the topic here: https://www.myintervals.com/blog/2011/06/08/clever-release-names-for-creative-developers/ [14:25:00] *** Quits: navcoin-bot (~navcoin-b@nav.community) (Remote host closed the connection) [14:25:09] *** Joins: navcoin-bot (~navcoin-b@nav.community) [14:34:06] @paul https://github.com/NAVCoin/navcoin-core/tree/aguycalled-patch-url-fallback travis passes now [16:00:40] @aguycalled is there a way to see in the wallet or via an rpc command how many coins the cf contains / how many coins are able to be allocated [16:10:29] Iirc there is [16:12:10] oh I misread that [16:12:21] not sure about the community fund [16:47:11] getinfo [16:47:13] or cfundstats [16:51:21] @prodpeak will you be implementing this into the navexplorer? [17:10:40] Yes. I'll be making a community fund page [22:35:52] @aguycalled we should reach out to whoever runs https://openalias.org/ and get them to add us to the list [22:36:08] https://cdn.discordapp.com/attachments/416000318149754881/461298645275246592/Screen_Shot_2018-06-27_at_00.35.53.png [22:37:14] fluffypony does