-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revised Lotus Node/Client Versioning #12072
Comments
@rjan90 : I'm putting things down about lotus docs that are triggering about release versions when reading through them:
|
I think using the highest number release would be ideal. Currently the process of updating the version for the Edit: This should also have been poiting to v1.26.2 or v1.26.3. v1.26.0 will not sync the current mainnet. So current process is human error prone. |
Understood. I added a subtask for "Update release process to have a step for updating the Lotus version for all docs". Ideally we automate this, but at the minimum it needs to be in the checklist so it doesn't get forgotten. |
@rjan90 : I assume as part of this we want to also make the shift to always branch from master, even for network upgrade related releases? I didn't see that stated anywhere. I created a discussion reply on it in #12020 (comment) so we can confirm that's the case. If it is, we'll need to add some done criteria and tasks to the tasklist of this issue. |
I did some issue description updates discussing branch strategy and timing. |
When this gets taken on lets also discuss:
|
I have started a draft PR for updating the LOTUS_RELEASE_FLOW.md document here: #12322. It is very preliminary, and there are items/discussions in this issue ticket that we need to discuss and figure out, that needs to be updated in that PR. |
This takes release issue changes and observations from #12109 with also having an eye towards the upcoming release process changes per #12072 . The general goals here are: 1. Have a checkbox step for each step a releae engineer should take. 2. Reduce duplication in the template itself. Where content should be duplicated, there is a comment for the issue creator to handle the copy/pasting.
…egy items (#12364) * docs: update LOTUS_RELEASE_FLOW with recent FAQs and branch/tag strategy items This was done as additional content to potentially add per #12322 . It includes content I saw in #12020 and #12072 that wasn't previously included. * Updates from self-review. * docs: Clarify node/miner release branching docs: Clarify node/miner release branching * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> --------- Co-authored-by: Phi <orjan.roren@gmail.com>
This takes release issue changes and observations from #12109 with also having an eye towards the upcoming release process changes per #12072 . The general goals here are: 1. Have a checkbox step for each step a releae engineer should take. 2. Reduce duplication in the template itself. Where content should be duplicated, there is a comment for the issue creator to handle the copy/pasting. * Removed experimental syntax testing. * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Addressing feedback about version string update in master * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Clarifying with comments that backport step doesn't really apply to RC1. * Cleanup Changelog prep steps. Addded some commands for helping identify holes in changelog. --------- Co-authored-by: Phi-rjan <orjan.roren@gmail.com>
This is being done in support of #12072
The subset of work for deprecating the |
…ect#12356) This takes release issue changes and observations from filecoin-project#12109 with also having an eye towards the upcoming release process changes per filecoin-project#12072 . The general goals here are: 1. Have a checkbox step for each step a releae engineer should take. 2. Reduce duplication in the template itself. Where content should be duplicated, there is a comment for the issue creator to handle the copy/pasting. * Removed experimental syntax testing. * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Addressing feedback about version string update in master * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Clarifying with comments that backport step doesn't really apply to RC1. * Cleanup Changelog prep steps. Addded some commands for helping identify holes in changelog. --------- Co-authored-by: Phi-rjan <orjan.roren@gmail.com>
This takes release issue changes and observations from #12109 with also having an eye towards the upcoming release process changes per #12072 . The general goals here are: 1. Have a checkbox step for each step a releae engineer should take. 2. Reduce duplication in the template itself. Where content should be duplicated, there is a comment for the issue creator to handle the copy/pasting. * Removed experimental syntax testing. * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Addressing feedback about version string update in master * Update documentation/misc/RELEASE_ISSUE_TEMPLATE.md Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Clarifying with comments that backport step doesn't really apply to RC1. * Cleanup Changelog prep steps. Addded some commands for helping identify holes in changelog. --------- Co-authored-by: Phi-rjan <orjan.roren@gmail.com>
…egy items (#12364) * docs: update LOTUS_RELEASE_FLOW with recent FAQs and branch/tag strategy items This was done as additional content to potentially add per #12322 . It includes content I saw in #12020 and #12072 that wasn't previously included. * Updates from self-review. * docs: Clarify node/miner release branching docs: Clarify node/miner release branching * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> --------- Co-authored-by: Phi <orjan.roren@gmail.com>
* Preliminary update to the LOTUS_RELEASE_FLOW document Preliminary update to the LOTUS_RELEASE_FLOW document * docs: update LOTUS_RELEASE_FLOW with recent FAQs and branch/tag strategy items (#12364) * docs: update LOTUS_RELEASE_FLOW with recent FAQs and branch/tag strategy items This was done as additional content to potentially add per #12322 . It includes content I saw in #12020 and #12072 that wasn't previously included. * Updates from self-review. * docs: Clarify node/miner release branching docs: Clarify node/miner release branching * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@protocol.ai> --------- Co-authored-by: Phi <orjan.roren@gmail.com> * Apply @BigLep suggestions from code review These were self-committed to make it easier to propose additional changes on top. * Apply remaining @BigLep suggestions from code review * Added terminology section * More editing Major items were answering: Why isn't Lotus Miner released more frequently? Why is the `releases` branch deprecated and what are alternatives? * Update LOTUS_RELEASE_FLOW.md Co-authored-by: Steve Loeppky <biglep@filoz.org> * fix: double spacing and minor typos fix: double spacing and minor typos * fix(docs): link to LOTUS_RELEASE_FLOW.md from CONTRIBUTING.md fix(docs): link to LOTUS_RELEASE_FLOW.md from CONTRIBUTING.md --------- Co-authored-by: Steve Loeppky <biglep@protocol.ai> Co-authored-by: Steve Loeppky <biglep@filoz.org>
* chose: deprecate "releases" branch by providing clear messaging This is being done in support of #12072 * fix: restore contents of makefile restore contents of makefile, which seems to have been deleted accidentally * Revert "fix: restore contents of makefile" This reverts commit 9de27df. * Made the message stand out more and also print to STDERR * Adjusted workflow actions in releases branch to not run on pull_request so they aren't triggered by changes to the releases branch * Update Makefile Co-authored-by: Phi-rjan <orjan.roren@gmail.com> * Update Makefile Co-authored-by: Phi-rjan <orjan.roren@gmail.com> --------- Co-authored-by: Phi <orjan.roren@gmail.com>
@rjan90 : is there more you think we should do here? We had these items open:
I think this is covered in filecoin-project/lotus-docs#746 right?
I had added this. While I think it's good so we're not so text heavy, I don't think it's a priority currently. I'd rather take it on the next time we have a discussion with ourselves or others and wish we had a diagram. At that point in time, it will be clearer on the specific diagram we want. While I could come up with something here, it's not sharp in my mind if someone said "You have one hour to go make a diagram that is useful for contributors. Go!" As a result, I am good if we close this out unless you think there is more we ned to do here. |
Agreed that we can close this out now. Remaining tasks should be covered by lotus-docs#746 |
This is a tracking issue for revising the Lotus Versioning
Problem to solve
We need to revise the versioning strategy of Lotus to adopt a more user-friendly approach, moving away from the mandatory (even) and feature release (odd) versioning scheme that has been the norm for the last years.
Why Important
Since LOTUS_RELEASE_FLOW.md was first written ~3 years ago, Lotus' stability and release quality have both increased. This proposal minimizes the need for having a "mandatory even" version that can be easily patched. Instead, by default, a hotfix can be applied to the latest production release, even if it includes additional backwards compatible features since the last network upgrade.
Historical Context
Historically, Lotus used an even and odd versioning scheme where
even minor
versions indicated mandatory releases (network upgrades) andodd minor
versions indicated feature releases.Reasons for Change
MAJOR
.MINOR
.PATCH
) will be easier for users to understand and follow.User/Customer
Lotus Client users
Notes
After the Lotus v1.28.0 release, which brings the changes for the next network upgrade (nv23), we will move away from the even and odd versioning.
The format will be
MAJOR
.MINOR
.PATCH
:MAJOR
if there are major changes to Lotus (e.g., if we re-architect).MINOR
whenever there is a network upgrade, API breaking change, or non-backwards-compatible feature enhancements.PATCH
whenever there are backwards-compatible bug fixes or feature enhancements.Concerning branching:
A key callout is that a Lotus release that has the functionality for a network upgrade may likely have commits that haven't been deployed to production yet (besides new FIP functionality).
This means a release accompanying a network upgrade may have commits that aren't essential and haven't been deployed to production. This is a simplifier and we think the risk is acceptable because we'll be doing releases more frequently (thus the amount of commits that haven't made it to a production release will be smaller) and our testing quality has improved since years past. (There is more discussion on this here.)
We expect:
Tasks
The text was updated successfully, but these errors were encountered: