Repository navigation
Contributors: Planned Cleanup - please comment #1114
Description
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
Docsand will include an updated DocFX project settings and file,docfx.json. - Svg.Custom - A duplication of
Svg.Skiaproject file. Move toTestsdirectory .
Activity
mrbean-bremen commentedon Dec 28, 2023
Branching strategy:
I personally favor workflows with one main branch. I always ended up with this one after having tried several variants (including a
developand amasterbranch 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 thedevelopand amasterbranches 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/mainbranch versions, if somebody else is maintaining them 😁. I would only renamemastertomain, as this is the standard nowadays, and I personally get always confused withmaster, as I'm so used tomainnow.Removing the old branches is fine, they are unneeded leftovers.
Removing Old/Unused Directories
Removing
BuildProcessTemplatesandNugetis certainly fine.Svg.Customis there to add tests withNO_SDCdefine - 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.jsonis fine, of course.paulushub commentedon Dec 28, 2023
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
developbranch, you still have a say before a release.OK! move it to the
Testsfolder to reflect that. I have just checked and it is behind the one inSvg.Skia.I hope there is no issue if this is synchronized with the
Svg.Skiaversion.mrbean-bremen commentedon Dec 28, 2023
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 commentedon Dec 28, 2023
sealed, but it never happen since Jun 29, 2021.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 commentedon Dec 29, 2023
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 commentedon Dec 29, 2023
You meant
Maintainers are allowed to edit this pull request.feature? It is available.mrbean-bremen commentedon Dec 29, 2023
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.