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

Fixed couple of typos #77

Merged
merged 1 commit into from
Jan 19, 2023
Merged

Fixed couple of typos #77

merged 1 commit into from
Jan 19, 2023

Conversation

sfnuser
Copy link
Collaborator

@sfnuser sfnuser commented Dec 23, 2022

Fixed couple of typos

@hdamker
Copy link
Collaborator

hdamker commented Jan 10, 2023

Also fine with the obvious fixes. Just thinking about the appropriate version (number) to target.

Two options:
a) fix v0.8.0 to v0.8.1 (a bugfix, not sure if there could be client implementations break, the minor version would just allow to see that something changed)
b) correct it only in v0.9.0 (so target the PR new to dev-v0.9.0 branch)

@eric-murray @jlurien what are your thoughts?

@eric-murray
Copy link
Collaborator

My preference would be that approved PRs get their own version number, rather than "rolling up" multiple PRs into a larger update. So this should be v0.8.1 (as it is documentation changes and should not be breaking any client implementations).

Of course, this begs the question as to what would happen if another PR that itself required a minor version increment was raised and approved before the dev-v0.9.0 branch was approved. I'd suggest that branches should be named after the feature they are implementing / fixing rather than the expected target version number, and the version number only assigned when the PR is merged.

But this problem could also be avoided by exhaustively discussing proposed changes in a related Github issue first before raising the PR, rather than raising the PR prematurely and then debating it for months. In that case, approving the PR should be a formality, and the required version number then known in advance.

@jlurien
Copy link
Collaborator

jlurien commented Jan 10, 2023

This v0.8 is special as it is a milestone for MWC. However I think it is OK to correct these detected typos, and if we change anything in yaml updating to 0.8.1 is good for tracking. We may think also in having some changelog.md to document the changes between versions, and it may be useful to have as well all past versions in a history folder. Especially, the v0.8.Z version should be easily accesible when we merge a future version.

Regarding future versions and branches, my understanding is that now we have a dev-vX.Y branch for next relevant version where all new PRs are proposed until we decide that we can consolidate that branch as a new version and merge it to main. Any unresolved PRs in this dev- branch should then be moved to the a new dev branch for subsequent version.

Independently to this I agree that it is good to open first an issue and get some initial consensus, although in the end a proposal is better understood and commented in a PR.

@kaikreuzer
Copy link
Contributor

This discussion sounds to me as if there isn't yet a clear branching/versioning strategy (what is always a complex topic indeed, but one cannot escape it).

Many (if not most) Github projects consider the main branch to be the "latest" code that will eventually be the next release. Therefore, the main branch is the default against which PRs are automatically opened (as is the case for this repo as the setting has not been changed). Projects then rather branch off older releases (such as 0.8.x) to provide further patch releases from such branches, while continuing the latest development on main.

From a contributors perspective, the branch against which PRs are by default created (here: main) is the one where they should be merged. Contributors do not care about your version/release management - so if you merge it here for the future 0.9.0 release, this is fine and you are still free to decide to also cherry-pick it to an 0.8.x-branch, where you could decide to do a 0.8.1 patch release from.

I agree that it is good to open first an issue and get some initial consensus

For major features where it is not clear where they are heading, I agree. For PRs like this one at hand, your processes must allow to very quickly and easily merge it. The only discussion that could happen is the one about the decision to backport it for patch releases or not - but that can imho happen after a merge.

@hdamker hdamker merged commit ee5e8fc into camaraproject:main Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants