Closed ilgooz closed 8 months ago
as said on signal:
[we could set up] just an auto workflow every 1st of month that pushes a monthly tag. something like 0.$yr.$mo, $yr = year-2020. so sept/2023 is 0.3.9, then 0.3.10, 0.3.11, 0.3.12, 0.4.1. so short, predictable and understandable, and semver-ish
I propose this to keep semver compatibility:
v0.0.1-dev.2023.09.15
, todayv0.0.1-dev.YYYY.MM.DD
, next timesOr v0.0.1-dev.5783.06.29
for today's Hebrew calendar date, offering a unique and timeless feel to versioning.
@moul sounds good.
I'll create the tag v0.0.1-dev.2023.09.15
for @gnolang/devx's immediate needs.
If we then want to change it to the hebrew calendar, we can do it without breaking version sorting (as jewish year > gregorian year).
My apologies, I was in the process of testing the 'generate release' feature (and applied it to the previous releases as well).
You can find the tag and release here: https://github.com/gnolang/gno/releases/tag/v0.0.1-dev.2023.09.15
Over to you, @thehowl!
October 1st snapshot ready 🎉
https://github.com/gnolang/gno/releases/tag/v0.0.1-dev.2023.10.01
Hey guys, closing this issue; but feel free to reopen if you believe it's not enough.
Terrific. Thanks guys @moul @zivkovicmilos This should be enough for now. We have one PR already tested ready to run on a schedule on our side to pick up the latest release of GnoVM. thanks everyone
(reopening as I want to automate :) )
This one was automated: https://github.com/gnolang/gno/releases/tag/v0.0.1-dev.2023.11.01
We're using gnovm in the IDE/playground. It would make things easier for us if the core team could tag gnovm on a regular basis so we can be notified when there are changes in gnovm and ship newer versions. We also plan to enable our users to choose from different versions of gnovm.
To begin, we need to create at least one tag for gnovm.