Is project being maintained? about xmlparsing HOT 16 OPEN

Turns out, you can't have a podspec dependency that's a fork with the same name. Unfortunately, because I have a new library with a podspec that depended on my XMLParsing fork, I had to pick a different name like XMLCoder. I hope you might be interested in using the new renamed fork while the original XMLParsing looks as not being maintained.

XMLCoder includes contributions from unmerged PRs to XMLParsing from @regexident, @edc1591, @salavert and @Lutzifer. It also adds unit-tests and Travis CI builds on top of that and I'm very happy to merge more contributions if anyone's interested.

Thanks.

from xmlparsing.

For what it's worth I just submitted four fixes …

• Made XMLEncoder.OutputFormatting.prettyPrinted actually do something – XMLParsing so far has been ignoring its provided OutputFormatting.
• Fixed use of precondition(…) testing for container emptyness – These cause XMLParsing to crash as is.
• Improved .gitignore and removed tracked *.xcuserdata files – Just some git minor house-keeping.
• Added missing visibility declarations – XMLHeader right now is inaccessible to external use due to internal .init(…).

… and would be happy to help out maintaining the project, if you'd add me as a contributor, @ShawnMoore (and maybe even create an org for it?).

from xmlparsing.

Please see #14 . I'm currently maintaining a fork of the library. @ShawnMoore merged my PR to framework-ify this repo, but then did not tag the repo so that we could actually consume it as a framework. :/ I've gone ahead and tagged my fork, and published for all to use.

from xmlparsing.

Perfect. Thanks @dingwilson. Glad to see it live on

from xmlparsing.

@ShawnMoore I saw that you made a few commits to the repo. Will you continue maintaining this project? If so, would you like me to transfer the ownership of the CocoaPod to you?

from xmlparsing.

Make that five 🤓:

• Added support for decoupled, type-dependent node-encoding strategies

Next-up: adding fixed-order encoding and I'll finally be able to write GPX. 😑

from xmlparsing.

Just curious, is there a way to grant someone else privileges to accept PQ's?

from xmlparsing.

@stonedauwg yes there is. @ShawnMoore would have to add the person as a collaborator, but then that person would have write access to the repo, and would be able to merge PRs.

from xmlparsing.

Yes, “collaborator” is what I meant, not “contributor”. Thanks @dingwilson !

Collaborator does not necessarily mean “sudo” though. GitHub allows for protecting a branch, so that e.g. at least one collaborator needs to accept via code review, etc. But given @ShawnMoore ‘s apparent rare activity here that’d probably defeat the purpose to a certain degree.

If it was my project I’d move it into an org to reduce the burden and select 2 collaborators to help out with the maintainance/development. Then I’d add mandatory code review to ensure quality control etc (2 collaborators so that there’s enough movement in merging/responding to PRs).

And last but not least once the project has reached a reasonable level of maturity I'd go for a proposal to add the implementation to Swift's stdlib (either verbatim/modified or have it at least act as a proof of concept accompanying an evolution proposal). 🙃

from xmlparsing.

@ShawnMoore could you chime in on this topic?

ShawnMoore/XMLParsing has the potential of filling a major gap in the Swift stdlib.
Yet there is lots of stuff piling up here with no apparent future for the project in sight.

from xmlparsing.

Hey all, many thanks for you contributions, I think I've cherry-picked most if not all mergeable PRs, you folks created recently, within my fork and added a new key decoding strategy on top of that and a first unit-test.

@ShawnMoore I'm happy to create to a new PR within this project if there's any chance this project is not abandoned after all.

Otherwise, please feel free to use my fork: https://github.com/maxdesiatov/XMLParsing/

from xmlparsing.

good job @MaxDesiatov

from xmlparsing.

Thanks, @MaxDesiatov!

Looks like I'll be doing any future work by contributing to XMLCoder then. 💪
Shame to see a hard fork end up being the only viable option, though. 😕

from xmlparsing.

Thank you for the feedback, I have same concerns, happy to hear any suggestions with workarounds if possible.

@ShawnMoore I'm happy to submit PRs with my changes and merge the fork back, please let me know if there's any chance those could be reviewed. Thank you for creating the original library!

from xmlparsing.

Agreed.

Btw, what’s your stance on creating an organization (with say the most active current contributors as collaborators to get things started) to encourage more contributions from others and ensure it stays alive for good?

from xmlparsing.

As far as I know, collaborators can be added to public repositories that even aren't attached to an organisation. I'd like to wait a bit and see if XMLCoder gets any traction, PRs, issues and active contributors in general, happy to add maintainers based on the amount of contributions.

I do plan to set up an organisation for maintaining a few more Swift libraries under the same umbrella. But again that's a future plan that totally depends on the amount of external interest there libraries would get.

from xmlparsing.