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 section in README about release versioning #47

Merged
merged 3 commits into from
Aug 3, 2021

Conversation

grantseltzer
Copy link
Contributor

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.

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.
@rafaeldtinoco
Copy link
Contributor

rafaeldtinoco commented Aug 3, 2021

Major releases are cut when backwards compatibility is broken or major milestones are completed, such as reaching parity with libbpf's API.

Agreed.

Minor releases are cut to incorporate new support for libbpf APIs.

Yes. If we follow a 1:1 feature with libbpf like we're doing, then this will work.

Patch releases are cut to incorporate important individual or groupings of bug fixes.

Yes.

libbpf support numbering indicates the minimum required libbpf version that must be linked in order to ensure libbpfgo compatibility. For example, v0.2.1-libbpf_0.4.0 means that version 0.2.1 of libbpfgo requires v0.4.0 or newer of libbpf.

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 ?

@grantseltzer
Copy link
Contributor Author

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.

Great idea, and your english was perfect. Added.

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 ?

Sounds great!

rafaeldtinoco
rafaeldtinoco previously approved these changes Aug 3, 2021
Copy link
Contributor

@rafaeldtinoco rafaeldtinoco left a 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>
@grantseltzer
Copy link
Contributor Author

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.

@grantseltzer grantseltzer merged commit c500b62 into main Aug 3, 2021
@geyslan geyslan deleted the release-versioning branch April 4, 2023 12:52
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.

2 participants