This project is on hold

[aaubry]

After a long time without touching this repository, I came to the conclusion that I no longer have the will to work on it. This is a free time project and lately I want to spend that time on other things. I don't have the energy to work on features that were in development, review pull requests or look into issues. Even writing this post got delayed for weeks.

I started this project because I wanted to use YAML in .NET and there wasn't any library available to do so. Over the years I've worked to improve it based on my personal needs or on feedback from other users. In the last few years, however, I haven't had the need / oportunity to use YamlDotNet neither on personal nor professional projects. This provides little incentive to keep updating it.

I may return to this project in the future, but for now I don't have the energy to even review pull requests or issues. I apologize to all the people who took the time to develop a feature or report an issue.

Perhaps this project should find some other maintainers, but I don't really know how to proceed. There have been some people in the past who made significant contributions, but I don't know if they would want this additional burden. I'm open to suggestions.

Thanks

[jarek108]

thats a great shame. thank your for your work until this point. hope someone is willing to step up and take over. best of luck

[ltrzesniewski]

Many thanks for this library! I hope you'll find new maintainers.

If I may suggest something: the project status is an important piece of information, so could you please add this info to the readme and pin the related issue? Thanks!

[aaubry]

Done.

[sellorio2]

Is there a currently supported library you recommend? Will you continue to release updated rebuilds for new .net versions?

[aaubry]

I don't know of any other library that is currently maintained. If I get pull requests to target newer .net versions, I will merge and release them.

[Blackclaws]

I'm wondering whether there is any hope of simply transferring this project to the dotnet foundation where there might be people willing to maintain it in the long term. I think its a rather important piece of software to have as a lot of configuration is done in yaml these days.

[SimonCropp]

simply transferring this project to the dotnet foundation where there might be people willing to maintain it in the long term

thats not a service the dnf provides . it doesnt supply maintainers or help a project find maintainers

[Blackclaws]

It doesn't supply or help find maintainers, but it might give the project a bit more visibility which could attract maintainers.

[JuergenGutsch]

This is a cool and quite useful project.
It would be an honor to help maintain the project.
Since it would be a side project for me as well it would be helpful to have one or two more people to maintain it.

[EdwardCooke]

I would be willing to help maintain this project as well. It's pretty critical in our build and release pipelines, especially for Kubernetes.

[EdwardCooke]

I have a fork of this project almost ready. It has a large number of bug fixes that I found after updating the YAML tests to the latest version. Just working through the rest of them. If we don't hear from @aaubry maybe we can work off that with a new nuget package?
Things in my fork that I've done.

• Solution builds and works in VS 2022
  • Removed unsupported .net version (netstandard 1.3 and framework 2.0), this made the building work and simplifies the project
• Added net60 target
• Updated yaml unit tests to latest of 2022
• Fixed a large number of the errors that where found in new unit tests
  • This also is fixing a few of the issues that were reported in the issues of this repository

I'm continuing to fix the rest of the errors from the unit tests.

[aaubry]

Hi! I'm inviting you both as collaborators. I don't really know how we should proceed from here, but I think it will be better to keep working on this repository. There's no need to publish a separate package, I will assist you with that part. Just let me know what you need.

[EdwardCooke]

Fantastic! I'll be creating a PR/branch with my changes and get them back in here.

[JuergenGutsch]

Thanks @aaubry!
Fully agree, there no need to move to a different repository yet. Let's keep the infrastructure as long as it is working

[daveaglick]

Thank you for all your work! Hopefully the project finds a new maintainer, but even if it doesn't you've done your part bringing it into the world and maintaining it to this point. Go do what excites you, and there's no obligation to do otherwise :).

[aaron-meyers]

FYI for those wondering there is a fork of YamlDotNet called SharpYaml at https://github.com/xoofx/SharpYaml which appears to be still maintained. I haven't used it so don't have any idea how much it has diverged (the README suggests that the serialization customization has diverged significantly).

We continue to ship this library (YamlDotNet) in production applications in Microsoft Power BI and I know other teams at Microsoft use it as well. Thanks @aaubry for all you've put into this.

[nickcampau]

SharpYaml just updated it's readme doc (see below) to reflect the same fate as this library. IMHO SharpYaml has been better at handling YAML reading/writing than YamlDotNet but neither of them are fully support the YAML 1.2 spec. That leaves the dotnet community without a reliable option to handle YAML documents. With the explosion of systems/services switching configuration setting over to use YAML it is a pressing issue to have a reliable library or devs will likely be forced to use another language that has proper support.

SharpYaml Readme snippit :

NOTICE:
This project is no longer actively maintained since 2016, but it's still accepting Pull-Requests.
Small improvements and fixes are welcome, but big refactoring won't likely be.
Please, open an issue in case you are not sure about the changes you want to bring before working on a PR.

[aaubry]

So far only @JuergenGutsch has expressed interest, but it would be good if more than one person would step up. If there are other people who are willing to volunteer as maintainers, maybe we can find an arrangement.

[JuergenGutsch]

There is @EdwardCooke who is also willing to help maintain this project. (see answer to my comment)

[EdwardCooke]

Now that we have maintainers, can we unpin or remove this discussion?

[aaubry]

I've locked the discussion. Should I delete it? I'm not sure if that's a good idea.

[EdwardCooke]

I think we could be safe to delete it. I do have a question though, maybe for another discussion, how do we cut a new release and get it to nuget? We've got quite a few bug fixes ready to go out.

[aaubry]

@EdwardCooke @JuergenGutsch I don't know where else to contact you, so I'll do it here. If you have a better idea, please let me know.

I need to share some information with you about how to so a release, and also how the CI process works. I think this information should be written somewhere so that any current or future maintainer can access it. I could either add a md file somewhere, or create a wiki page. Since this is information that is specific to the infrastructure and not the code itself, perhaps a wiki page makes more sense. What do you think?

[aaubry]

Also, currently the master branch is not protected. I never felt the need for that but with multiple maintainers, it is probably a good idea to prevent mistakes. What do you think?

[EdwardCooke]

I like the idea of protecting the master branch where, at a minimum, every change requires at least one reviewer and all changes have to happen through a PR, regardless of who makes the change or what is changed. It's a standard practice at many places.

I think a wiki page about the pipelines is a good idea.

You can also reach me by email at edward@frakkingsweet.com (I get a ton of spam already, so I'm not concerned about putting my address in here.)

[aaubry]

I have added information about the release process in the wiki. Please have a look and let me know if it is clear.