Release Process

[tintoy]

Let’s use this as a starting point for discussing (and eventually defining) our release process.

A couple of suggestions:

• Consider use of GitHub’s projects/milestones feature to track various releases and associate work items with them.
• Consider use of Gitter or an equivalent tool to enable discussions for coordination of work?
• Maintaining the change log - who and when? Just a basic guideline would be sufficient I think.

CC: @DoctorKrolic

[tintoy]

Examples where I could have done better (and having a process worked out may help):

• Improve handling of concurrent loads for MSBuild sub-projects msbuild-project-tools-server#103
• Cannot redefine/reassign a property in the same file msbuild-project-tools-server#100

[tintoy]

Maybe a Project to track work across language service and extension?

https://docs.github.com/en/issues/planning-and-tracking-with-projects/creating-projects/creating-a-project

[tintoy]

Use of labels for changelog generation:

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

[DoctorKrolic]

Well hello there) I've been putting this discussion away for quite some time and now I finally got here. My opinions on the suggested items are the following:

Consider use of GitHub’s projects/milestones feature to track various releases and associate work items with them.

It's probably not worth managing all of that since we both combined don't produce that much changes, that it requires separating it into milestones etc.

Consider use of Gitter or an equivalent tool to enable discussions for coordination of work?

I really like this idea, esp. given that I have several architectural change suggestions in mind that wouldn't bring immediate value, but would open new oppotunities in the long term, better testability etc. I think such changes are better to be duscussed somewhere outside the repo to not make too much noise here

Maintaining the change log - who and when? Just a basic guideline would be sufficient I think.

I think I've already mentioned my strategy on this, but let's fully formalize it here:

• During development in between releases we have # Upcoming section on the top of a changelog file
• When a PR results in a change, that is worth an item in a changelog, the person, who opens a PR also adds that item to the # Upcoming section
• If PR is on the server side after the PR is merged it's that person's responsibility to open a syncing PR on the client side and add an item to the changelog in that syncing PR

[tintoy]

Great - this sounds like something I can agree with 🙂

I'm overseas on vacation but will be coming back in a couple of days; I'll set a reminder to come back and look at this when I do.

[tintoy]

Ok, I'm back - can you sign into gitter.im and let me know what username you've chosen (you can sign in with GitHub BTW) so I can invite you to the chat? I've created an internal-only one for now but we can create a public one as well, later, if we need to.

[DoctorKrolic]

@doctorkrolic:gitter.im, same profile icon as here