Upgradable smart contracts - a new instance is created - migration

A new instance is created everytime I migrate my upgradable smart contract.
I am using openzeppelin upgrade plugins on truffle.
I tried what is discussed in https://forum.openzeppelin.com/t/openzeppelin-upgrades-step-by-step-tutorial-for-truffle/3579 but locally on Ganche

Related

Deploying a Smart Contract

If I were to deploy a smart contract for NFT's that I would want to sell which is the best way to do this. And is utilising Injected Web3 on Remix.ethereum.org an acctual option.
Also, if you have a large NFT project, it will only be realistically possible to deploy large amounts of NFTs using scripts in a solidity development framework.
If your deployment process simple, Remix IDE's injected web3 is a viable option.
If you need to run deployment scripts, for example to mint after deployment, run some test transactions, share your contract address on twitter(?) than frameworks such as hardhat are really useful. Because you can create complex deployment scripts with them. For hardhat, that is a JS file.
You can also do it with your bare hands. Compile your code with solc, get the bytecode maybe get the ABI too, send a transaction to the empty address putting your bytecode as data and have a contract on blockchain.

Warning Regarding extcodehash in Remix for openzeppelin-contracts

I have compiled the openzeppelin-contracts code in Remix IDE. Meanwhile, I have obtained the following warning.
Warning: The "extcodehash" instruction is not supported by the VM version "byzantium" you are currently compiling for. It will be interpreted as an invalid instruction on this VM. assembly { codehash := extcodehash(account) }
I am obtaining this warning for all recent versions of the EVM, and not just the byzantium one. I have tried to search for a solution regarding this warning, but without success. Would anyone know how to "fix" this issue?
The issue is that the contract imports from the OpenZeppelin Contracts GitHub master branch which needs a later compiler version.
You should only use code published in an official release of OpenZeppelin Contracts, the latest release is 2.3. When importing via GitHub on Remix you can specify the release tag, (otherwise you will get the latest code in the master branch).
The warning is caused by:
Compiler 0.5.3 has a default EVM version of byzantium whilst Compiler 0.5.11 has a default EVM version of petersburg. You may also want to use Compiler version 0.5.11.
The imports using version 2.3.0 of OpenZeppelin Contracts would be:
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.3.0/contracts/token/ERC721/ERC721Full.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.3.0/contracts/math/SafeMath.sol";
Alternatively to using Remix, have a look at the Getting Started guide for information on how to setup a development environment.
If you have questions on using OpenZeppelin you can ask in the Community Forum: https://forum.openzeppelin.com/
Disclosure: I am the Community Manager at OpenZeppelin

how to create a project from a template within youtrack with external hub integration?

I am experimenting with latest hub and youtrack on a linux machine,
I installed latest versions (2019.2 and 2019.1 respectively) and enabled the hub integration in youtrack. (not using https for the moment, old plain http is used)
What happened is this:
When I try to create a project i am always switched to Hub (is this correct? i did not find anything on JetBrains docs)
If I create a project from the hub interface and then click on the left panel to add a "Youtrack service" then i am offered the option to create only "default, scrum and kanban" projects that are the standard ones provided by JetBRains, however if i had already created a project and saved as template that project is not offered to me as an option to be the base of the new one.
If i use youtrack with the internal hub, all works as expected and the template projects are available as a starting point for new projects.
This happens as well with older versions (2018.4) of hub and youtrack.
As far as I recall this is bug in Hub yet to be fixed.
It seems correct, as with an external Hub installed projects are always created from there
2-3. There's known issue with that: https://youtrack.jetbrains.com/issue/JPS-9928

Compiling Titanium Modules from GitHub

After a few days of failure I realize I need more insight than google can deliver.
I am attempting to include a module in my otherwise working fine Titanium project but am not having any luck. The module in question is Ti.MapPlus, a fork of the standard Ti.Map module that I am already using. The GitHub repository does not have a compiled release, and it is not available via Gitt.io.
I have tried to create a new Mobile Module Project without success; but suspect that this is the best route.
Can anybody walk me through the steps of getting the module working globally?
There are some releases here: https://github.com/AppWerft/Ti.MapPlus/releases

MvvmCross Reachability on Windows Phone

I'm trying to use Cirrious.MvvmCross.Plugins.Network.Reachability on Windows Phone 8. I have added the Network Plugin to my WP8 project and my core. The plugin bootstrapper has been added to the Bootstrap folder. I'm trying to pass an IMvxReachability in the constructor of one the dependencies of my View Model. When I run the app, I get this exception..
Failed to load ViewModel for type MyNamespace.MyViewModel from locator MvxDefaultViewModelLocator
Not all plugins and not all interfaces are available on all platforms.
Reachability was added to iOS because it was a requirement from the App Store.
The same interface is not currently available on any other platforms.
If you need to get hold of the implementation of an interface which might not always be available, then the ways to do this currently are using:
if (Mvx.CanResolve<T>())
myT = Mvx.Resolve<T>();
or (better):
Mvx.TryResolve<T>(out myT);
There is currently an open issue (feature request) to allow optional parameters for IoC construction - see https://github.com/slodge/MvvmCross/issues/239
There are currently no open requests for Reachability - native APIs do exist (sometimes with app-capability protection flags), but most Droid and Windows apps don't test for network state...