new conventions for v1.1.0

[plebhash]

tracker issue for the new conventions

• Consider using release branches #1124
• merge CONTRIBUTING.md + README-DEV.md #1140
• pre-push githook for fmt only + remove act #1039
• publish libs to crates.io on release tags #1142
• stop publishing some crates #1143
• global release docs #1154

[Fi3]

I'm also taking the opportunity to do some assessment on the current branches we have on the repo:

according to the conventions proposed in #1124, these branches should stay:

* `main`

* `v1.0.0`

* `v1.1.0`

* `v1.2.0`

it would be also good to keep these:

* `dev` (for some time, until we feel confident that the transition was successfully done)

* `workshop` which has some extra files that are convenient for https://github.com/stratum-mining/sv2-workshop

but the following branches seem old and outdated:

* `Fi3-patch-1`

* `POCRegtest-1-0-0`

* `POCRegtest-2-0-0`

* `bot/versioning`

* `sv1-proxy`

* `sv2-tp-crates`

@Fi3 do you know the historical context for these branches? Is there some reason we should keep them, or is it safe to delete them from the repo?

POCRegtest-1-0-0 POCRegtest-2-0-0 are from before the splitting in dev and main and are exactly what we want to do now, having branch with releases (in this case the release was a pre release POC) and the main branch, so I would leave them there for completeness. All the other branch can be removed.

[Fi3]

I summarize here the possible convention that I proposed in the call for versioning the entire project:

Super Simple

Just increment a number at every release 1, 2 ,3 ecc ecc. This is very simple and seems one of the most adopted.

Simil Semantic

we put majior version at 2, this because is stratum v2
at each release:
if we add a feature (like adding one extension, or a library) we increment minor version
otherwise we increment patch version

When there will be stratum 3 we increment majior

[plebhash]

I don't have strong opinions on which direction to follow for global release versioning of this repo

but here's some thoughts:

• if we consider that we eventually want to split the repos and have roles living somewhere else, we should stick with some convention that only covers for protocols here, and completely ignores whatever happens on roles
• if we change the convention, we should edit v1.0.0, v1.0.1 and v1.0.2 accordingly... otherwise it will be really confusing to have different standards co-living on the same repo

[GitGab19]

Taking into consideration this point:

• if we consider that we eventually want to split the repos and have roles living somewhere else, we should stick with some convention that only covers for protocols here, and completely ignores whatever happens on roles

Here some of my thoughts about it:

• I also think that global version should reflect what's going on with regards to protocols.
• I don't like the idea of bumping the major version to 2 now, since we are going to make some breaking changes.
• I think that we should reason as if we were at 0.0.2 in this moment.
  • I like the idea of bumping the major to 2.0.0 when we will reach the API stability necessary to say "Ok, the first stable version of Stratum V2 is officially out".

Given this, my proposal is to leave things as they are, bumping patch version number every time we fix a bug on some libraries, and bumping minor version number for every other case. If there will be some breaking changes on some releases, we will take care of communicating it through release notes and directly to entities which are in direct contact with us.
When we will do all the necessary protocols refactoring, we will need to work on creating a proper set of APIs (cc @plebhash), and after that I'm confident with bumping everything to 2.0.0

[GitGab19]

I'm also taking the opportunity to do some assessment on the current branches we have on the repo:
according to the conventions proposed in #1124, these branches should stay:

* `main`

* `v1.0.0`

* `v1.1.0`

* `v1.2.0`

it would be also good to keep these:

* `dev` (for some time, until we feel confident that the transition was successfully done)

* `workshop` which has some extra files that are convenient for https://github.com/stratum-mining/sv2-workshop

but the following branches seem old and outdated:

* `Fi3-patch-1`

* `POCRegtest-1-0-0`

* `POCRegtest-2-0-0`

* `bot/versioning`

* `sv1-proxy`

* `sv2-tp-crates`

@Fi3 do you know the historical context for these branches? Is there some reason we should keep them, or is it safe to delete them from the repo?

POCRegtest-1-0-0 POCRegtest-2-0-0 are from before the splitting in dev and main and are exactly what we want to do now, having branch with releases (in this case the release was a pre release POC) and the main branch, so I would leave them there for completeness. All the other branch can be removed.

@Fi3 I see your point, but at the same time those two branches won't be taken into consideration by anyone, since they are more than 2 years old, completely unmaintained. So I would clean them up, is it ok for you?

[Fi3]

Personally I would leave them here but not against removing them

[GitGab19]

@plebhash we can close this, right?
Or do we want to formalize the proposal regarding global release naming somewhere?