-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add RELEASING.md #403
Add RELEASING.md #403
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM besides my comment around how we should do hotfixes but its not blocking.
branch structure: | ||
|
||
* `master` - Reflects the latest `MAJOR.MINOR-dev` version. | ||
* `vMAJOR.MINOR` - Contains `MAJOR.MINOR` specific changes and point releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we dont need to keep these branches around since the tag's are an immutable branch and we can push hofixes without needing a branch for that tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How exactly would that process work? Create a hotfix branch based on the tag, tag that, and then delete the branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, so you would fetch the tag locally, checkout the tag, this puts you in headless mode, then you checkout a branch from that, make the change, commit that to the new local branch. Then tag that new commit. And just push the tag, which will also push the commit without needing the extra branch on the remote.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, sounds good to me, less steps = more better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, that means master
is the only release-related long-lived branch?
Want to make sure @lukesteensen is on board with this process, then I'll merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this sounds good, and I'd really like to see a script or tool (e.g. cargo-bump or cargo-release) to handle the bump/commit/bump/commit sections.
I'll save my argument for CalVer for a later date 😄
branch structure: | ||
|
||
* `master` - Reflects the latest `MAJOR.MINOR-dev` version. | ||
* `vMAJOR.MINOR` - Contains `MAJOR.MINOR` specific changes and point releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, that means master
is the only release-related long-lived branch?
RELEASING.md
Outdated
|
||
### Patch Releases | ||
|
||
1. Switch to the appropriate `vMAJOR.MINOR` branch. **You should not make point releases on the `master` branch!** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the tag instead of the branch, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, that means master is the only release-related long-lived branch?
Yes, based on @LucioFranco's recommendation. This would require us to branch off of whatever tag we're fixing. Make changes, tag that, and then delete the temporary branch. Does that make sense?
This should be the tag instead of the branch, right?
Yep, I'll fix.
fc28204
to
36212f4
Compare
Yeah, CalVer is interesting. We'll learn more as continue to release. I'm curious if we'll encounter any time-based requirements with our releases. |
…9103 feat(sources): `http_server` accepts query parameter wildcards
# [3.2.0](answerbook/vector@v3.1.3...v3.2.0) (2024-01-24) ### Bug Fixes * **sources**: `http_server` is not saving query params as key/val [733f3a9](answerbook/vector@733f3a9) - Darin Spivey [LOG-19104](https://logdna.atlassian.net/browse/LOG-19104) ### Features * **http_server source**: add all headers to the namespace metadata (vectordotdev#18922) [3772b19](answerbook/vector@3772b19) - Darin Spivey [LOG-19103](https://logdna.atlassian.net/browse/LOG-19103) * **sources**: `http_server` accepts query parameter wildcards [6627a95](answerbook/vector@6627a95) - Darin Spivey [LOG-19105](https://logdna.atlassian.net/browse/LOG-19105) ### Miscellaneous * Merge pull request vectordotdev#403 from answerbook/darinspivey/LOG-19103 [896eaed](answerbook/vector@896eaed) - GitHub [LOG-19103](https://logdna.atlassian.net/browse/LOG-19103)
No description provided.