Skip to content
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

Merged
merged 5 commits into from
May 23, 2019
Merged

Add RELEASING.md #403

merged 5 commits into from
May 23, 2019

Conversation

binarylogic
Copy link
Contributor

No description provided.

@binarylogic binarylogic requested a review from lukesteensen May 22, 2019 16:42
Copy link
Contributor

@LucioFranco LucioFranco left a 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.
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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 Show resolved Hide resolved
@binarylogic
Copy link
Contributor Author

Want to make sure @lukesteensen is on board with this process, then I'll merge.

Copy link
Member

@lukesteensen lukesteensen left a 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.
Copy link
Member

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!**
Copy link
Member

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?

Copy link
Contributor Author

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.

@binarylogic
Copy link
Contributor Author

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.

@binarylogic binarylogic merged commit 5612d4a into master May 23, 2019
@binarylogic binarylogic deleted the add-releasing branch May 23, 2019 18:11
aholmberg pushed a commit to aholmberg/vector that referenced this pull request Feb 14, 2024
…9103

feat(sources): `http_server` accepts query parameter wildcards
aholmberg pushed a commit to aholmberg/vector that referenced this pull request Feb 14, 2024
# [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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants