Git Workflow

[johnhooks]

@smhg how would you like to manage the PR flow for improvements.

• Do you like the idea of a development branch?

  If this is acceptable, we need to get development into a state we can all agree on, and then make sure new work into it is code reviewed and accepted. Otherwise the changes will become too large to actually review.

• Do you prefer a trunk based flow?

  It looks like historically, this has been the approach. Changes are merged into master, and it is not kept in sync with releases.

[erikyo]

If I may chime in, I believe in this case the development branch flow could work well, as it involves a series of changes that shouldn't be immediately merged into master.

For all other cases, I naturally prefer the standard flow, what we could call PR/merge. However, in this instance, the changes are too extensive for that approach, risking a PR with thousands of lines changed, which 'I wouldn't want to be the reviewer of' :)

[johnhooks]

I think we can do it in smaller chunks. We would just need to accept that at the start the type checking would fail, which is the current state of the package, so there is no structural change to introduce failing type checks. We would work to fix it in small PR changes.

[smhg]

I don't have enough experience with teamwork and git to have a real opinion about those approaches.
In general, these are my priorities with any library I maintain:

• Follow semver and break as little as possible. If it can't be clarified in a 2-line changelog 'breaking:' line how to upgrade, find a different approach. Also, don't break everything in one big version bump, but split it out. One improvement at a time. This saves people headaches.
• Release as often as possible. Sidenote: in this light, I'm sad all 'meta' changes in the TS PR aren't released yet. The TS PR should not keep them back.

Using git tools (cherry pick, fix branches, rebase,...) to facilitate to above is my absolute preference. But that might not answer your question.

[johnhooks]

That answers the question. It sounds a lot like a trunk based workflow. We need to make sure the PRs are concise, can be merged into master and released, minimizing breaking changes as much as possible.

[smhg]

I think it is wise to first decide (if not already) on the question #91. As I don't have any meaningfull experience with TypeScript, the outcome of that might make me unable to contribute to this library.

[johnhooks]

the outcome of that might make me unable to contribute to this library.

In light of that, my opinion would be to start with JSDocs and see how far it can take us. It will fit the need and ensure it doesn't result in you being unfamiliar with the code base.

[smhg]

I don't need to contribute to the future of this project. I would only be sad if it lost its focus.

But in light of incremental changes, if the Jsdoc approach is feasible (eg not a waste of your time). We don't need to decide who maintains the project yet. We can take it step by step (my favourite approach as you might have noticed by now 😉).