docs(CONTRIBUTING): refactor, add versioning, remove nightlies #2477

thehowl · 2024-07-01T19:21:44Z

This PR modifies our CONTRIBUTING guide, adding a section on an informal versioning scheme we are temporarily adopting to communicate breaking changes on the Gno repository.

It also removes CI workflows for nightly builds; while retaining the master builds.

After we merge this, I'll proceed to release the 0.1.0 :)

There is a bit of a re-organization of CONTRIBUTING I batched together with these changes, to update some outdated information, link to the documentation where necessary, and provide information on new policies and suggestions adopted in the repository; including disencouraging rebases and giving write access to maintainers.

Contributors' checklist...

Added new tests, or not needed, or not feasible
Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
Updated the official documentation or not needed
No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
Added references to related issues and PRs
Provided any useful hints for running manual tests
Added new benchmarks to generated graphs, if any. More info here.

codecov · 2024-07-01T19:24:34Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.81%. Comparing base (10a6f7e) to head (0b0c8a2).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2477      +/-   ##
==========================================
+ Coverage   54.71%   54.81%   +0.10%     
==========================================
  Files         583      583              
  Lines       78499    79098     +599     
==========================================
+ Hits        42947    43355     +408     
- Misses      32344    32471     +127     
- Partials     3208     3272      +64

Flag	Coverage Δ
contribs/gnodev	`23.81% <ø> (ø)`
contribs/gnofaucet	`15.31% <ø> (+0.85%)`	⬆️
contribs/gnokeykc	`0.00% <ø> (ø)`
contribs/gnomd	`0.00% <ø> (ø)`
gno.land	`62.54% <ø> (ø)`
gnovm	`59.97% <ø> (-0.02%)`	⬇️
misc/autocounterd	`0.00% <ø> (ø)`
misc/genproto	`0.00% <ø> (ø)`
misc/genstd	`73.90% <ø> (ø)`
misc/goscan	`0.00% <ø> (ø)`
misc/logos	`17.38% <ø> (-0.31%)`	⬇️
misc/loop	`0.00% <ø> (ø)`
tm2	`54.48% <ø> (+0.05%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

CONTRIBUTING.md

moul · 2024-07-01T19:45:52Z

CONTRIBUTING.md

+Before that happens, the Gno team has adopted an informal versioning system
+for its 0.MINOR.PATCH versions, which works as follows:
+
+- The Gno team releases, weekly-ish, a new PATCH version which will contian a


Suggested change

- The Gno team releases, weekly-ish, a new PATCH version which will contian a

- The Gno team releases, weekly-ish, a new PATCH version which will contain a

CONTRIBUTING.md

moul · 2024-07-01T19:52:14Z

I don't get why a manual weekly release is better than an automatic nightly release.

Regarding the PATCH and MINOR. I also don't understand why we currently care about this. Do we have anything that justifies not only updating the patch or just staying with v0.0.1-dev.YYYY.MM.DD?

thehowl · 2024-07-01T22:09:15Z

I don't get why a manual weekly release is better than an automatic nightly release.

Regarding the PATCH and MINOR. I also don't understand why we currently care about this. Do we have anything that justifies not only updating the patch or just staying with v0.0.1-dev.YYYY.MM.DD?

The primary need for versioning comes from some recent changes on master, like #2019 and #2382, or the change Milos made removing the timestamp from the transaction, and how these versions interact with users of the gno package, often through gnoclient; like supernova, or a specific tool I wrote for the challenge series. From one day to the next, they broke; the reason was simply that they were using versions of the client and server that were incompatible.

We need a simple system, that can immediately point out to a user when they're using incompatible versions; ie. a counter that keeps track of versions having significant breaking changes. This is not something that is possible with the nightly snapshot versions; ie. it is more understandable that 0.4.1 is incompatible with 0.3.11 rather than v0.1.0-dev.20240612 with v0.1.0-dev.20240528.

The reason to prefer manual releases comes from a few places:

Since the problem partly comes from the go.mods, having a tag or having a go get on @master wouldn't then make much of a difference compared to getting @latest (if we were to have nightly releases every day).
Doing it manually means, for instance, that we can hold off releases for a while as we deem it necessary if we want to batch together a release with several breaking changes.
Releases create a notification email. Dependabot does a good job of filling up my inbox every monday; if I can avoid another meaningless inbox every day I think it's better :)

Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>

…gno into dev/morgan/contributing-changes

moul · 2024-07-02T00:12:02Z

The primary need for versioning comes from some recent changes on master, like #2019 and #2382, or the change Milos made removing the timestamp from the transaction, and how these versions interact with users of the gno package, often through gnoclient; like supernova, or a specific tool I wrote for the challenge series. From one day to the next, they broke; the reason was simply that they were using versions of the client and server that were incompatible.
We need a simple system, that can immediately point out to a user when they're using incompatible versions; ie. a counter that keeps track of versions having significant breaking changes. This is not something that is possible with the nightly snapshot versions; ie. it is more understandable that 0.4.1 is incompatible with 0.3.11 rather than v0.1.0-dev.20240612 with v0.1.0-dev.20240528.

Your suggestion seems premature. I think partial support for multiple versions is worse. Regular rebasing on master is simpler. Manual minor vs patch selection complicates releases and adds confusion while debugging. Regular pulls while we break things often would be clearer (up-to-date VS outdated).

The reason to prefer manual releases comes from a few places:

Since the problem partly comes from the go.mods, having a tag or having a go get on @master wouldn't then make much of a difference compared to getting @latest (if we were to have nightly releases every day).

Doing it manually means, for instance, that we can hold off releases for a while as we deem it necessary if we want to batch together a release with several breaking changes.

Releases create a notification email. Dependabot does a good job of filling up my inbox every monday; if I can avoid another meaningless inbox every day I think it's better :)

1. and 2. seem contradictory. Point 1 implies no one cares about versioning, while Point 2 suggests the versioning cycle needs to be stricter. Who's the target? What's the need?

3. I get the point, but it's not enough to justify the switch.

Nightly tags offer an advantage over @latest, like having Docker images. This was requested by the DevX team.

Edit: I'm fine with replacing nightlies with manual releases. However, I don't understand why you want to introduce the more advanced versioning system at this time.

mvertes

Just some few nit-picking. Thank you, nice improvements.

CONTRIBUTING.md

thehowl · 2024-07-08T21:21:27Z

Discussing with @moul, I convinced him to:

Go for manual releases
And have them consider a notion of "breaking / non-breaking"; but in order to make this not arbitrary, add a CI workflow that checks for some common "user flows" against what's on the portal loop; like adding a package, or submitting a transaction, and testing if it works. These are CI checks that are completely "allowed to fail" (also because they're bound to happen if the PL is down or for other networking problems); but they can alert about breakages against the current published code, and thus give us a good notion of what's breaking or not
- See-also: "User Flow" integration test #2159

I'm reverting to draft to kick-start developing a few of these checks

ajnavarro

LGTM

ajnavarro · 2024-07-10T08:10:10Z

CONTRIBUTING.md

+version numbers.
+
+Before that happens, the Gno team has adopted an informal versioning system
+for its 0.MINOR.PATCH versions, which works as follows:


This is also following semver:

https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase

https://semver.org/#spec-item-4

moul · 2024-09-21T02:37:21Z

Discussing with @moul, I convinced him to:

I don't remember what you said, but I don't feel convinced at the moment.

Is there anyone who can share how having v0.1.0 and v0.2.0 has changed their life?

moul

need to be convinced again

docs(CONTRIBUTING): refactor, add versioning, remove nightlies

b1f309b

thehowl self-assigned this Jul 1, 2024

thehowl requested review from ajnavarro, moul, a team and jaekwon as code owners July 1, 2024 19:21

moul reviewed Jul 1, 2024

View reviewed changes

CONTRIBUTING.md Show resolved Hide resolved

moul reviewed Jul 1, 2024

View reviewed changes

CONTRIBUTING.md Outdated Show resolved Hide resolved

thehowl and others added 4 commits July 2, 2024 00:12

Update CONTRIBUTING.md

96c821c

Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>

fixup

162dd5e

Merge branch 'dev/morgan/contributing-changes' of github.com:gnolang/…

e265b93

…gno into dev/morgan/contributing-changes

fixup gnodev

0b0c8a2

mvertes approved these changes Jul 3, 2024

View reviewed changes

CONTRIBUTING.md Show resolved Hide resolved

CONTRIBUTING.md Show resolved Hide resolved

CONTRIBUTING.md Show resolved Hide resolved

thehowl marked this pull request as draft July 8, 2024 21:21

ajnavarro approved these changes Jul 10, 2024

View reviewed changes

michelleellen mentioned this pull request Jul 31, 2024

Minutes: Public Dev Calls [every Wednesday] gnolang/meetings#37

Open

thehowl mentioned this pull request Sep 3, 2024

Semantic or other meaningful versioning of the GnoVM #2755

Open

Kouteki mentioned this pull request Sep 16, 2024

Minutes: Core Staff Weekly Syncs [every Monday] gnolang/meetings#36

Open

moul requested changes Sep 21, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs(CONTRIBUTING): refactor, add versioning, remove nightlies #2477

docs(CONTRIBUTING): refactor, add versioning, remove nightlies #2477

thehowl commented Jul 1, 2024

codecov bot commented Jul 1, 2024 •

edited

Loading

moul Jul 1, 2024

moul commented Jul 1, 2024

thehowl commented Jul 1, 2024 •

edited

Loading

moul commented Jul 2, 2024 •

edited

Loading

mvertes left a comment

thehowl commented Jul 8, 2024

ajnavarro left a comment

ajnavarro Jul 10, 2024

moul commented Sep 21, 2024

moul left a comment

	- The Gno team releases, weekly-ish, a new PATCH version which will contian a
	- The Gno team releases, weekly-ish, a new PATCH version which will contain a

docs(CONTRIBUTING): refactor, add versioning, remove nightlies #2477

Are you sure you want to change the base?

docs(CONTRIBUTING): refactor, add versioning, remove nightlies #2477

Conversation

thehowl commented Jul 1, 2024

codecov bot commented Jul 1, 2024 • edited Loading

Codecov Report

moul Jul 1, 2024

Choose a reason for hiding this comment

moul commented Jul 1, 2024

thehowl commented Jul 1, 2024 • edited Loading

moul commented Jul 2, 2024 • edited Loading

mvertes left a comment

Choose a reason for hiding this comment

thehowl commented Jul 8, 2024

ajnavarro left a comment

Choose a reason for hiding this comment

ajnavarro Jul 10, 2024

Choose a reason for hiding this comment

moul commented Sep 21, 2024

moul left a comment

Choose a reason for hiding this comment

codecov bot commented Jul 1, 2024 •

edited

Loading

thehowl commented Jul 1, 2024 •

edited

Loading

moul commented Jul 2, 2024 •

edited

Loading