search

stratum-mining / stratum

stratum
https://stratumprotocol.org
Other
208 stars 124 forks source link

new conventions for `v1.1.0` #1141

Closed plebhash closed 3 weeks ago

plebhash commented 1 month ago

tracker issue for the new conventions

plebhash commented 1 month ago

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:

it would be also good to keep these:

but the following branches seem old and outdated:

@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?

plebhash commented 1 month ago

a similar analysis for tags:

the following tags follow the conventions proposed in #1124:

but the list below seems to be following some previous release convention:

@Fi3 would it be safe to delete these?

Fi3 commented 1 month ago

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 commented 1 month ago

a similar analysis for tags:

the following tags follow the conventions proposed in #1124:

* `v1.0.0`

* `v1.0.1`

* `v1.0.2`

but the list below seems to be following some previous release convention:

* `binary_codec_sv2-v0.1.3`

* `binary_codec_sv2-v0.1.4`

* `binary_sv2-v0.1.5`

* `binary_sv2-v0.1.6`

* `buffer_sv2-v0.1.1`

* `buffer_sv2-v0.1.2`

* `common_messages_sv2-v0.1.5`

* `const_sv2-v0.1.1`

* `const_sv2-v0.1.2`

* `derive_codec_sv2-v0.1.3`

* `error_handling-v0.1.0`

* `framing_sv2-v0.1.4`

* `framing_sv2-v0.1.5`

* `job_negotiation_sv2-v0.1.0`

* `mining_proxy_sv2-v0.1.0`

* `mining_sv2-v0.1.0`

* `network_helpers-v0.1.0`

* `noise_sv2-v0.1.2`

* `pool_sv2-v0.1.0`

* `quickcheck-v1.0.4`

* `quickcheck_macros-v1.0.1`

* `roles_logic_sv2-v0.1.0`

* `serde_sv2-v0.1.1`

* `serde_sv2-v0.1.2`

* `sv1_api-v0.1.0`

* `sv1_api-v0.1.1`

* `sv2_ffi-v0.1.3`

* `template_distribution_sv2-v0.1.5`

* `translator_sv2-v0.1.0`

@Fi3 would it be safe to delete these?

pretty sure that we can delete them but double check it

Fi3 commented 1 month ago

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 commented 1 month ago

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

but here's some thoughts:

GitGab19 commented 1 month ago

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:

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 commented 1 month ago

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 commented 1 month ago

Personally I would leave them here but not against removing them

GitGab19 commented 3 weeks ago

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