Contributors: Planned Cleanup - please comment

[paulushub]

Description

Currently planning to cleanup the project.

Removing Old/Unused Branches

Planning to add a develop branch, which will be the target of PR and use the master for releases.
The following branches are marked for deletion (all in the Stale tab):

• interaction
• mousescroll
• textEvents
• netcore2.2

Removing Old/Unused Directories

The following project folders are marked for deletion:

• BuildProcessTemplates - codeplex relics
• Nuget - contains older nuget packages and configuration

Also

• Tests/W3CTestSuite
  • Will separate the issues and pull-requests SVG/PNG files from the actual W3C Test Suite files
  • The W3C Test Suite files can be downloaded from GitHub repository I created for SharpVectors.
  • The W3C Test Suite files will be deleted from the W3CTestSuite folder - a readme file will be added.
• doc will be renamed Docs and will include an updated DocFX project settings and file, docfx.json.
• Svg.Custom - A duplication of Svg.Skia project file. Move to Tests directory .

[mrbean-bremen]

Branching strategy:

I personally favor workflows with one main branch. I always ended up with this one after having tried several variants (including a develop and a master branch with different names) over the years (both in my private projects and at work), plus feature branches for PRs. It always turned out that the additional work to test both the develop and a master branches and merging / cherry-picking commits from one the other did not have any benefits in the end.

In my own (Python) repos I only have one main branch (called main), from which I make releases. I usually do release branches, but release tags are actually sufficient - you can always make a branch from a tag if you plan patch releases for older versions.

That having said, I'm of course also fine with develop / main branch versions, if somebody else is maintaining them 😁. I would only rename master to main, as this is the standard nowadays, and I personally get always confused with master, as I'm so used to main now.

Removing the old branches is fine, they are unneeded leftovers.

Removing Old/Unused Directories

Removing BuildProcessTemplates and Nuget is certainly fine.
Svg.Custom is there to add tests with NO_SDC define - I would leave this as long as this is still needed. It should not be needed anymore after splitting out the rendering.

Tests/W3CTestSuite / docs

Yes, getting rid of the duplication would be nice.
Also agree about doc -> docs, that is more standard. Updating docfx.json is fine, of course.

[paulushub]

I personally favor workflows with one main branch.

Cool actually, but it becomes an issue if you have a public repository with workflow build.
Some PRs you want, but requires some polish, however the contributor may not be cooperating.
With the develop branch, you still have a say before a release.

Svg.Custom is there to add tests with NO_SDC define - I would leave this as long as this is still needed.

OK! move it to the Tests folder to reflect that. I have just checked and it is behind the one in Svg.Skia.
I hope there is no issue if this is synchronized with the Svg.Skia version.

[mrbean-bremen]

Some PRs you want, but requires some polish, however the contributor may not be cooperating.

Not sure I understand. You mean the contributor does not make required changes, and also does not allow you to do them in their branch, but you want to merge them and adapt afterwards, and don't want to do this in the main branch? I'm probably missing something...

[paulushub]

• The PR Follow MS guidelines for custom exception types. #826 only needed to delete sealed, but it never happen since Jun 29, 2021.
• Recently on SVGImage, I asked a contributor to add XML Docs it never happened - I had to reject the PR 😢

These changes are easy enough to add yourself, clear the PR loads and continue with your work.

[mrbean-bremen]

Usually it is possible for maintainer to adapt PRs if needed (I have done this in such cases in other projects), I'll check tonight if this is not the case here.

[paulushub]

You meant Maintainers are allowed to edit this pull request. feature? It is available.

[mrbean-bremen]

Yeah, right. For me, it seems easier to do this editing a PR from time to time (it does happen quite rarely in my experience) than to maintain another branch. But YMMV and as I wrote, I'm fine with another workflow, if that suites you better.

[mrbean-bremen]

Thanks for moving these to discussions - the number of real issues is high enough already 😀