-
Notifications
You must be signed in to change notification settings - Fork 95
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 section in README about release versioning #47
Conversation
This describes @yanivagman's idea in #39. I would immediately follow up this PR merge with the cutting of a new release based on the scheme described here.
Agreed.
Yes. If we follow a 1:1 feature with libbpf like we're doing, then this will work.
Yes.
Perfect. -- Can we add a disclaimer like (and feel free to rephrase as English is better on your side): Do note that some distributions might have local changes to their libbpf package and their version might include backports and/or fixes differently than upstream versions. In those cases we recommend that libbpfgo is used statically compiled. And then I can do a simple write on how to clone libbpfgo and write a oneliner and have it compiled with dynamic libbpfgo dependency and with static libbpfgo dependency. What do you think ? |
Great idea, and your english was perfect. Added.
Sounds great! |
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
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
I pushed another commit when I realized I had some redundant information in my previous one. Also added a TOC. Also want to note that I confirmed having '-' or '_' doesn't break anything with versioning go modules. |
This describes @yanivagman's idea in #39. I would immediately follow up this PR merge with the cutting of a new release based on the scheme described here.