In blockchain.cpp for v0.14.0.0, the stagenet fork is
{ 10, 269000, 0, 1550153694 },
{ 11, 269720, 0, 1550225678 },
which means it already happened as far as I can tell. I thought the point of stagenet was always to be a mirror of mainnet?
The point of stagenet is to allow people to test without using testnet, which tends to reorg with short notice. If stagenet did not fork before mainnet, people could not test whether their code will break before it's too late.
Wasn't the point of stagenet to be run using the same version of monero software as current mainnet?
Yes. It is, just a couple weeks early so people have a chance to test before the fork.
testnet is also on v11 now which can be used for testing forks before they happen.
I think it's arguable that stagenet should be forked exactly at the same time as mainnet so as to avoid confusions for people wanting to test merchant services on stagenet.
As @moneromooo-monero stated, testnet is for experimenting new consensus rules and thus is expected to get reorged arbitrarily frequently.
Currently, there's no consensus rules being tested, so testnet and stagenet are effectively functioning identically.
@stoffu
I understand that. But if both testnet and stagenet fork before mainnet, then there is a period of time when there is no network to keep testing and developing using current monero software.
Also its fragments the network, because now there are two stagenets, v9 and v11. And its very confusing. For example, Monerjo wallet support stagenet. But witch one? v9 and v11? Kasisto is also on stagenet (https://amiuhle.github.io/kasisto/#/). But which one? What about xmr.to stagenet facet (https://community.xmr.to/faucet/stagenet/) or this faucet (http://stagenet.xmr-tw.org:38085/)?
All this is again confusing. If I move openmonero stagenet version to v11 (http://139.162.60.17:81/) it may be out of sync with other stagenet services. If I leave it on v9, same can happen.
Basally entire stagenet ecosystem that people rely on for development and testing their monero-based services and testing got fragmented. This situation happen last year with testnet, where there were 3 networks. So I was always under impression that stagenet was created to avoid it.
There are two because people did not update. If stagenet was forking on the 9th, there would still be two because people do not update. Less likely maybe, because the more you wait, the more likely everyone will have updated, but the point is that it's a matter of people not updating.
But give people moan if we do one way and people moan if we do the other, I'll just ignore stagenet next time, and people who actually use it can choose when it forks.
@moneromooo-monero
Also understand that. There is no golden solution for everything.
There is an assumption that having two stagenets is a bug, but could it actually be viewed as a feature?
You can use the v9 stagenet to test things that you want to deploy to the mainnet before the fork, and the new stagenet to test things that you want to ensure will work afterwards.
One thing is to give services and integrators the opportunity to test the fork in advance and in realistic enough conditions thanks to stagenet. I also believe because they have a different use than most users (relying much more on RPC, having different scalability needs, etc), they provide a valuable testing of the Monero fork itself.
A second thing is to make sure that a 1:1 copy of mainnet is always available, _even in the couple of weeks before the fork._
I don't think that these two goals are compatible (unless we add yet another network type), and for me the former is worth giving up on the later.
There was some issue this time between v9 and v11 simply because enough of us on stagenet did not update in time . Let's coordinate better next time!
Initially I didn't see the benefit of forking stagenet before mainnet, but now I see. The stagenet v11 has become vital in the last week or so for testing, development and upgrading of projects that I work on for the v11.
If there was no stagenet at v11, I would have to use testnet which may or may not have features that will end up in mainnet. So having stagenet v11 before mainnet v11 is the closed one can get in terms of testing grounds for the mainnet v11.
So it's as it's supposed to be.
+invalid