Bump Omni Core version to RC1

[dexX7]

Before releasing the release candidate, the version should be bumped to reflect the status.

• configure.ac#L13
• src/omnicore/version.h#L27

I think we should go with lower caps "rc1". Do you agree?

It would show up as version string "omnicore-0.0.10.0-rc1" and the following file names are expected after going through the Gitian build route (if I'm not mistaken):

• omnicore-0.0.10.0-rc1-linux32.tar.gz
• omnicore-0.0.10.0-rc1-linux64.tar.gz
• omnicore-0.0.10.0-rc1-osx-unsigned.tar.gz
• omnicore-0.0.10.0-rc1-win32-setup.exe
• omnicore-0.0.10.0-rc1-win32.zip
• omnicore-0.0.10.0-rc1-win64-setup.exe
• omnicore-0.0.10.0-rc1-win64.zip
• omnicore-0.0.10.0-rc1.tar.gz

@msgilligan: do you have any experience with software signing? Do you have an Apple Developer ID by any chance?

[zathras-crypto]

I'd actually like to merge up outstanding and do a -dev release for the dev@ mailing list ideally today with what we have, because I keep delaying the guys asking for binaries to test with and it'll be a contentious point again in the meeting tomorrow.

That way the guys can have something to play with while we finalize the last bits (documentation, feature activation etc) for a release candidate?

[dexX7]

Ahh, sorry @zathras-crypto. I missed a bunch of messages earlier.

I'm still away with my notebook, and be back in about 9 hours, and then I could fire up my building VM.

If you produce anything before then, you may go ahead.

Do you think people will still upgrade to the actual RC1/release/..., if binaries are published now?

[zathras-crypto]

Hey bud,

That would be really appreciated if you could :) I'm struggling to get gitian building going on a new 0.10 gitian setup at the mo...

Do you think people will still upgrade to the actual RC1/release/..., if binaries are published now?

Sorry - for clarity mate these binaries would be distributed to the dev@ mailing list only rather than "published" as it were - this is so folks like Craig/Marv/Adam/Sean/Patrick/others I'm forgetting and so on can start submitting issues for bugs - I said I'd get them some binaries and they said they'd test them out :) I figure we'll get some extra exposure to MetaDEx on testnet along with a bunch of UI feedback which can then be bugfixed along with the other bits we are still working on for the release candidate & release stages (documentation, feature activation etc etc).

These binaries at the current stage would have no activation system for new features so wouldn't be much use outside a testing scenario.

Thanks bud :)
Z

[dexX7]

I'm going to try to setup a VM here, but given the pretty long build times etc., I wouldn't be surprised, if I get home before I have results. Hehe.

We could (optinally) tag it as -internal, and flip this switch:

https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/configure.ac#L7:

define(_CLIENT_VERSION_IS_RELEASE, true)

As result, there is a yellow status warning on the overview page, explicitly stating it's a developer preview. What do you think? The tag is might be over the top, but the status bar warning seems appropriate in my opinion.

[zathras-crypto]

I'm going to try to setup a VM here, but given the pretty long build times etc., I wouldn't be surprised, if I get home before I have results. Hehe.

Sorry I didn't want to sound like I was being pushy mate :) Whenever you can do the builds is fine & appreciated greatly :)

We could (optinally) tag it as -internal, and flip this switch

Love both of those ideas - I just made the change to configure.ac and am rebuilding now to test, but nope I don't think that that's over the top at all - it's not a release so these seem entirely appropriate :)

[dexX7]

Okay, but I think we should actually tag it as -internal, once we're sure it works?

[zathras-crypto]

Okay, but I think we should actually tag it as -internal, once we're sure it works?

When you say tag it - sorry do you mean "tag it as -internal" as:

• change the version suffix from '-dev' to '-internal'
• tag it on github as an internal release/tag under the 'releases' section

[dexX7]

Well, that's sort of the question.

[zathras-crypto]

change the version suffix from '-dev' to '-internal'

This makes sense to me, given the purpose of the binaries

tag it on github as an internal release/tag under the 'releases' section

I don't see a whole lot of value to that as I think we're going to have our first release candidate within a week or so and it kind of "feels right" (I know, very helpful point hehe) to have that as our first tag/release on the repo.

[dexX7]

Hehe, I agree, mostly. The only reason would be to say "see, this is the build we have right here, you can check it out on GitHub", but referring to a commit should equally work, I guess.

Edit: but in this case, I'd leave the -dev, but nevertheless flip the no release switch.

[zathras-crypto]

The only reason would be to say "see, this is the build we have right here, you can check it out on GitHub", but referring to a commit should equally work, I guess.

I think these binaries will have a very limited run before we push out the first release candidate :)

but in this case, I'd leave the -dev, but nevertheless flip the no release switch.

Sure sure - I'm happy either way re -dev - I just tested the no release switch in configure and that looks good - shouldn't we do that for the release candidate also, and only flip it back when we actually release?

[dexX7]

shouldn't we do that for the release candidate also, and only flip it back when we actually release?

Generally we could use it, but for the release candidate I wouldn't. The RC should probably reflect the actual release 1 to 1, except the version string, so that the latest RC we release is identical to the actual release (except the version).

The status warning about not being a release may interfere with the alerting system, but we'll see. :)

[dexX7]

Say we publish 0.0.10-no-activation, and want to fire an alert targeting them, and only them, but not the actual-release-clients. How would we do that?

This is where the last digit of the version number would be handy, but given that it is reserved for minor releases (and not for revisions, build numbers, ...), I don't really see many options here.

[zathras-crypto]

Say we publish 0.0.10-no-activation, and want to fire an alert targeting them, and only them, but not the actual-release-clients. How would we do that?

The current alerting system doesn't allow for targeting specific builds - only versions under a certain value. So to fire an alert targeting 0.0.10-no-activation, but not targeting say 0.0.9.1/2 actual-release-clients is not currently feasible.

Let me consider if some changes to the alert system for 0.0.10 might allow for this. We could use an alert message that matches for version instead of checking it's > version for example to target a specific build. Do we need to do this though?

[dexX7]

The current alerting system doesn't allow for targeting specific builds - only versions under a certain value.

Ah sorry, I think I didn't make my point clear:

I think it would be great, if we'd have the ability to target all < 0.0.10-release clients, including the preview ones:

• 0.0.9.0
• 0.0.9.1
• 0.0.9.2
• 0.0.10.0-dev

But not:

• 0.0.10.0-rel

Generally, we could use an text based alert, which uses the client version. However, .10.0-dev and .10.0-rel have the same version number, so differentiating between them wouldn't be possible.

This isn't about -rel or -dev per se, but rather about the actual client - one with MetaDEx enabler and one without.

We could solve this by bumping the version for the release, but as mentioned above:

This is where the last digit of the version number would be handy, but given that it is reserved for minor releases (and not for revisions, build numbers, ...), I don't really see many options here.

Maybe I see this issue, even though it's actually none?

[zathras-crypto]

Ah sorry, I think I didn't make my point clear

Ahh I understand now hehe...

We could solve this by bumping the version for the release, but as mentioned above...

Well, we may need to make changes to alerting at this point for feature activation by message - let's think about this for a moment - take a feature like Class C - is that going to be activated by message? And if so, the old paradigm of alerting using isTransactionTypeAllowed to verify client support isn't going to give us coverage. So perhaps we need additional capabilities in alerting to go in tandem with feature activation by message? In which case we could do something about 0.0.10.0-dev and 0.0.10.0-rel having the same internal version (which I agree isn't cool).

[dexX7]

And if so, the old paradigm of alerting using isTransactionTypeAllowed to verify client support isn't going to give us coverage.

Why? I mean, sure, we could change the mechanism and combine the activation with a warning etc., but imho the most straightforward way to handle the activations in general could be, and this is mostly unrelated to the actual format of the notification-transaction (i.e. which fields, version, ...), to extract some block height, as well as a feature identifier, from that transaction, and then update/replace the block height restriction entry (e.g. MSC_METADEX_BLOCK = 999999 to = 370000).

having the same internal version (which I agree isn't cool)

What stops us from using different version numbers?

As alternative to 0.0.10.0 for dev, and 0.0.10.1 for release, we may take a look at the practise Core uses: dev versions have x.y.99, which are then bumped + 1 for the release. If we follow this approach, we would be at 0.0.9.99 currently.

[zathras-crypto]

Why?

Because the alerting system uses the function isTransactionTypeAllowed() with a transaction type and version to verify client support and forces a shutdown if the transaction type is not supported by the live blockheight. In the case of something like Class C, there is no transaction type/version to validate.

What stops us from using different version numbers?

Nothing, and I quite like the idea of being at 0.0.9.99 for dev versions :)

[dexX7]

Ah, sorry, very good point. I only thought about transactions, but not other types of things that could be enabled, like class C support.

We also need a way to identify features, when enabling them, so we may add something similar to the block height restrictions, but with feature identifiers.

Nothing, and I quite like the idea of being at 0.0.9.99 for dev versions :)

Great, I like it, too. :)

[dexX7]

Reddit:

F2Pool (~ 20% of hashrate) appear to have just switched to a minrelaytxfee of 0.0005 BTC / kB, which has lead to them producing small blocks for the last 6 hours or so.

This value would require an output value for a class B simple send (two compressed public keys) of 0.000342 BTC. I guess it's good news that we switch to OP_RETURN then. :)

[zathras-crypto]

Interesting - also see bitcoin#6402