Proposal: reset versioning to `alpha`

[0x009922]

I've always been in protest of labeling Iroha 2 versions as pre-release-candidate and release-candidate. It does not make sense: even though we are at 2.0.0-rc.2.0 now, we are still shipping and planning major breaking changes to the data model and to the APIs.

It would make sense for Iroha 2 to be in alpha stage until we really stop making major changes and API stabilises.

I realise that it is unlikely to happen, but am creating this issue to document the insanity that was happening for years.

[takemiyamakoto]

It's true that RC is usually used when the features are code complete. There can still be bug fixes, but with an RC there shouldn't be new features added, which we plan to have. Whether it should be alpha or beta is a topic for discussion, but I think given the expanded scope of the release we shouldn't increment RC tags. Maybe we could do rc2-alpha as a tag so people know we are building off the rc2 release.

[s8sato]

I completely agree that the current RCs are anything but release candidates. I don’t understand why we pushed forward with RC1 despite missing key features. When RC1 was released, we set up a milestone to ensure the next one would be a true release candidate, but midway through, team pressure led me to release RC2. We should have taken the term RC far more seriously.

That said, I don’t think we need to introduce yet another version name and confuse people. Instead, we should endure the discomfort of using the name RC2, concentrate our resources on the features that truly matter, and make RC3 the real RC.

[s8sato]

We tend to lose sight of the big picture and dive into the small tasks we can tackle right now, even though those efforts will be swept away by the truly big-picture work that follows. The reason our specifications never settle is also because we never confront the real challenges. We need to buckle down and address the greatest difficulties first, including the thousand-series issues (#1xxx).