Prepare installers, replace icons, define version

[dexX7]

With #91, at least for Windows, the setup and icons currently like this:

It should be rebranded to Omni Core.

• Prepare installer
• Replace setup icons
• Define version

[dexX7]

Currently still missing:

1. updating the version on a low level, because it shows 0.10.2 of Bitcoin Core
2. embedding the documentation files to the installer [...] once they are ready

Regarding the version.. should we really use 0.0.10? I'm a bit annoyed by the second zeros.. :)

And I'm wondering: how comes the numering started with 0.0.7 back then, and not 0.1 or so?

[dexX7]

@zathras-crypto: we should probably replace the uninstall icon, too. It's currently some stock icon of Nsis:

[zathras-crypto]

we should probably replace the uninstall icon, too. It's currently some stock icon of Nsis...

I see that quite a lot and kind of think users associate that icon with uninstall don't you think?

[dexX7]

Fair point, it's the default NSIS icon ("NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers." - http://nsis.sourceforge.net), but I didn't know, if it's used anywhere else. I looked through other programs, and I saw it once, or twice. :)

Let's quickly discuss the install package. I like how it's done with Bitcoin Core: some documents are copied and attached, such as a readme, release notes, etc.

Actually, it's the whole doc/, and further, the doc/README_windows.txt is copied into the base dir, and renamed to readme.txt, as well as COPYING (to COPYING.txt).

What do you think about creating src/omnicore/doc/, and move the API docs, etc. there? I'd basically like to consider src/omnicore/ as project dir, and handle it as if it were completely seperated from Bitcoin Core (if all this makes sense).

To close this issue, I'd further like to set the version/version-string, on the packet/installer/...

[zathras-crypto]

What do you think about creating src/omnicore/doc/, and move the API docs, etc. there? I'd basically like to consider src/omnicore/ as project dir, and handle it as if it were completely seperated from Bitcoin Core (if all this makes sense).

I'm happy with this, though I think there should be one document left over in src/doc called omnicore.txt that just contains a single line stating to look in src/omnicore/doc for Omni Core related documentation.

Regarding the version.. should we really use 0.0.10? I'm a bit annoyed by the second zeros.. :)

IIRC the 0.0.x code numbering were to be the 'alpha' code, and when we felt it was ready for 'beta' it would move to 0.x code. I guess it's all a question of semantics really.

[dexX7]

I guess it's all a question of semantics really.

Yeah, sure, it is.

Given that it's going to be a consensus breaking update, are we going to increment the number in the middle now? Like:

0.1.0
  ^-- consensus break, so bump larger than "z" in "x.y.z"?

[zathras-crypto]

0.1.0
  ^-- consensus break, so bump larger than "z" in "x.y.z"?

Up until now it has been:

0.0.9.0
    ^-- consensus break, so bump larger than "y" in "w.x.y.z"?
0.0.9.1
      ^-- no consensus break, so bump larger than "z" in "w.x.y.z"?

I'm open to changing the versioning scheme though, if we wanted to drop one of the zeros from the next release?

Given that it's going to be a consensus breaking update

Only once the foundation activates the new features :) hehe

[dexX7]

As mentioned in #91, I adopted this:

define(_OMNICORE_VERSION_MILESTONE, 0)
define(_OMNICORE_VERSION_MAJOR, 0)
define(_OMNICORE_VERSION_MINOR, 10)
define(_OMNICORE_VERSION_PATCH, 0)
define(_OMNICORE_VERSION_STATUS, dev)

Which results in the version string "0.0.10.0-dev" and the installer file omnicore-0.0.10.0-dev-win64-setup.exe.

I suggest we bump dev to rc1 for the first release candidate and ideally we omit the last zero, as well as the suffix for the release.

I choose "milestone", because the first digit is often "set to 1", once the product "is out of beta status", "reached stable level", etc., so I adopted this term.