How about some guidelines?

[sewbacca]

I would like to have some opinions about how to handle this fork (@Ismoh, ogsadmin?). Following questions are on my mind:

• How should we handle Pull Requests? I have just merged Fix incorrect assert() handling #10, since it is a quite simple one and I have also tested it locally, so I hope that its okay. However what about larger features? Is it enough if one of us, reviews tests and and merges them?
• When should we publish a new version? Would a single merge be considered enough or should we wait a week or two, to see if some more bugfixes accumulate? And who does it?
• I have just found another bug, given a new manuel test suite. Since I have write access, should I simply add this one directly here on master or create a PR? I think opening a new issue beforehand is a good idea either way.
• Any preferences about a consistent commit message schema? Tomblind didn't seem to have one and @Ismoh seems to use (Fix/Update/Add) <message>
• Maybe a minor point, since we have GitHub Discussions, but what about communication? Do you think, these are enough?

[Ismoh]

Hey @sewbacca, thanks for spotting in!
I appreciate your engagement and I fully agree on your thoughts!

Let me add my thoughts and maybe we find some solutions:

How should we handle Pull Requests? I have just merged #10, since it is a quite simple one and I have also tested it locally, so I hope that its okay. However what about larger features? Is it enough if one of us, reviews tests and and merges them?

We should add general testing per commit or minimum per pull request. We can use GitHub actions for this. But in addition I prefer manually testing locally.

When should we publish a new version? Would a single merge be considered enough or should we wait a week or two, to see if some more bugfixes accumulate? And who does it?

I would prefer trunk based development; or in other words: there will be a main/master branch and branches for bugfixes, new features etc. Everytime there is a PR merged into main/master, there will be a new version + release based on SemVer.
All of this can be done by GitHub action workflows.

I have just found another bug, given a new manuel test suite. Since I have write access, should I simply add this one directly here on master or create a PR? I think opening a new issue beforehand is a good idea either way.

I also prefer creating an issue, then a branch based on the issue + PR into master when tested.

Any preferences about a consistent commit message schema? Tomblind didn't seem to have one and @Ismoh seems to use (Fix/Update/Add)

I am about to stick to Convential Commits, but would also be new to me, which isn't a problem. Reason for convential commits is, to be able to create auto generated release notes.

Maybe a minor point, since we have GitHub Discussions, but what about communication? Do you think, these are enough?

There is already a discord server for all my github stuff. Wouldn't be a problem to me, to add a new section to the server to have a faster response time for discussions.

[sewbacca]

We should add general testing per commit or minimum per pull request. We can use GitHub actions for this. But in addition I prefer manually testing locally.

I agree that automated tests would be awesome! I would recommend to only test the external debug adapter interface directly, with no internal testing units per se. However it would take myself quite some time to get a testing framework up and running. Do you know how to get that up and running fast?

I would prefer trunk based development; or in other words: there will be a main/master branch and branches for bugfixes, new features etc. Everytime there is a PR merged into main/master, there will be a new version + release based on SemVer.
All of this can be done by GitHub action workflows.

The trunk based development makes sense to me. Though I am not sure if versions would spiral out of control, if we release a new release for every PR, always. If we would do that, the changelog would be a single feature / bugfix every time.

If we go full semver, then technically, for major version 0, any bump in minor or patch may be considered a breaking change. Shall we release a 1.0.0 or extend the requirements of n.x.y (n > 0) for also versions with n == 0. Also what exactly do we version? I would suggest to only version the launch.json contributions and the client debugger interface, which is also what I mean by the "external debug adapter interface".

I also prefer creating an issue, then a branch based on the issue + PR into master when tested.

I think this process is sound, but how do we want to get PRs back into the master branch? via squash, rebase or merge? Personally I am in favor of squash or rebase, to keep the history clean and concise. Squashing has the benefit of not cluttering the history, depending on the personal commit style of the PR author.

Since we talked about testing earlier, I would like to adopt the model of adding tests, based on issues and possibly linking them in code as well as adding a note in the commit message. This is why I want to mainly test the external interface, as it will make creating tests directly from user issues easy. So the process would look something like this: issue -> branch -> create a commit with a failing test-> fix the issue / implement the feature -> PR into master (similar to test driven development, but without the additional burden of testing all units).

I am about to stick to Convential Commits, but would also be new to me, which isn't a problem. Reason for convential commits is, to be able to create auto generated release notes.

That is an interesting commit schema. I am unsure about some stuff, here are my thoughts:

• I like it, if fix messages describe the bad behaviour, instead of what the good one should be (i.e. "fix crash on debug start" instead of "fix check index to prevent crash on debug start)
• Inline with this, originally I like to have verbs instead of nouns as types (thinking of what does a commit do to a repository? what changes between versions?), though I can imagine using nouns instead
• I don't like the bracket syntax for scopes, how about "<type> <scope>: <message>" or "<verb> <message> <scope>? i.e. "feat launch.json: add platform property" or "add platform property to launch.json"
• Conventional commits suggest that compound commits should be avoided at all cost. While I can see value in that, I believe some changes cannot be easily seperated into multiple commits, as long as all features/bugfixes are documented in the message. Also this is important for chosing which way we choose to add PRs (squash, rebase or merge).

There is already a discord server for all my github stuff. Wouldn't be a problem to me, to add a new section to the server to have a faster response time for discussions.

I think this is up to you to decide. I like to think alot about what I say on GitHub discussions, but for some issues, faster response times are beneficial.

[Ismoh]

I'll come back to this soon.
https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits

https://github.com/conventional-changelog/conventional-changelog

https://github.com/absolute-version/commit-and-tag-version?tab=readme-ov-file#should-i-always-squash-commits-when-merging-prs