You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 22, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 22, 2024. It is now read-only.
Community should fork this project and maintain it on its own. #349
Hi! Yes, I’m sorry for “breaking the news” in the comment. I always planned (and still do) to make a list of repositories I no longer wish to maintain and asking the community for a fork before archiving them. I wasn’t going to suddenly archive this repo, I just was responding to your issue since you asked. I think in practice its not a big difference since I’m very poorly/barely maintaining it now, anyways…
@sagikazarmark Extremely supportive of forking this under Viper. Viper is a great project. I’d be happy to update the README and support that as the official, I think that project has shown good OSS stewardship.
And I also agree with the linked comments that a fork is the best option, rather than a transfer.
Reacted by Krisztian Gacsal, Márk Sági-Kazár, Tomáš Karela Procházka, Ramiz Polic, Jonathan Bluett-Duncan, Eron Wright, Tom Vendolsky and Bartek Pacia
Thank you very much. I'll leave the project unarchived for now and let you handle migrating any issues or PRs you want. Then at some future point I'll update the README to point to the Viper project and archive.
I started pulling in some of the more serious bug fixes into the fork.
I'll tag 1.6.0 soon with the current module name and then tag a v2 renaming the module, so the fixes can still be used as a drop-in replacement.
I also plan to send a message to all pending issues and PRs asking them to resubmit in the new repo, so that we can do some cleanup around stale issues/PRs.
Reacted by Sonny, Jerry Bendy, Tomáš Karela Procházka, Krisztian Gacsal and xu0o0
@sagikazarmark I mistakenly thought the go-viper org and Viper project in reference this whole time was the official spf13/viper project. I can see you're the top contributor to spf13/viper, and I assume maintainer but not 100% sure. Can you make it clear what your association is and what the go-viper org is? (I'm still thankful for your fork and work here and I'm not accusing you of anything untoward, just want to make sure this is totally clarified)
Yes, I'm a maintainer of Viper (spf13/viper) and the go-viper organization is associated with that project. The long-term plan is to move some of the remote providers and encoding plugins to external repos to reduce the number of dependencies in the core Viper project.
The core repository will remain under @spf13's personal account to avoid breaking the thousands of imports. :)
Curious if transferring the repository is an option, so that GitHub's redirects lead visitors to the right place, preserve more history such as tickets and pull requests, and go modules to function without "replace" rules for versions of the module before renaming.
I see the other repository is now "ahead" a couple of commits, but the module hasn't been renamed yet, so that may complicate things a bit (this repository's git would probably have to be aligned before that)
@mitchellh I can open a PR to add a notice to the readme if you want me to, but it may be better if it comes from you. Let me know which one you prefer.
Activity
mitchellh commentedon Dec 17, 2023
Hi! Yes, I’m sorry for “breaking the news” in the comment. I always planned (and still do) to make a list of repositories I no longer wish to maintain and asking the community for a fork before archiving them. I wasn’t going to suddenly archive this repo, I just was responding to your issue since you asked. I think in practice its not a big difference since I’m very poorly/barely maintaining it now, anyways…
@sagikazarmark Extremely supportive of forking this under Viper. Viper is a great project. I’d be happy to update the README and support that as the official, I think that project has shown good OSS stewardship.
And I also agree with the linked comments that a fork is the best option, rather than a transfer.
sagikazarmark commentedon Dec 18, 2023
Thank you @prochac for opening this issue.
@mitchellh I forked the project under go-viper (https://github.com/go-viper/mapstructure). (There isn't much in there yet, but that's where Viper subprojects will gravitate eventually)
Thank you for all the work you've put into this project (well...all of them). I wish you all the best in your next endeavor!
mitchellh commentedon Dec 18, 2023
Thank you very much. I'll leave the project unarchived for now and let you handle migrating any issues or PRs you want. Then at some future point I'll update the README to point to the Viper project and archive.
❤️
sagikazarmark commentedon Dec 18, 2023
Thank you @mitchellh !
I started pulling in some of the more serious bug fixes into the fork.
I'll tag 1.6.0 soon with the current module name and then tag a v2 renaming the module, so the fixes can still be used as a drop-in replacement.
I also plan to send a message to all pending issues and PRs asking them to resubmit in the new repo, so that we can do some cleanup around stale issues/PRs.
sagikazarmark commentedon Dec 19, 2023
Tagged a new version with the old import path: https://github.com/go-viper/mapstructure/releases/tag/v1.6.0
Also started to work on v2 with the new import path: https://github.com/go-viper/mapstructure/releases/tag/v2.0.0-alpha.1
mitchellh commentedon Dec 20, 2023
@sagikazarmark I mistakenly thought the
go-viperorg and Viper project in reference this whole time was the official spf13/viper project. I can see you're the top contributor to spf13/viper, and I assume maintainer but not 100% sure. Can you make it clear what your association is and what the go-viper org is? (I'm still thankful for your fork and work here and I'm not accusing you of anything untoward, just want to make sure this is totally clarified)sagikazarmark commentedon Dec 20, 2023
@mitchellh no worries!
Yes, I'm a maintainer of Viper (spf13/viper) and the go-viper organization is associated with that project. The long-term plan is to move some of the remote providers and encoding plugins to external repos to reduce the number of dependencies in the core Viper project.
The core repository will remain under @spf13's personal account to avoid breaking the thousands of imports. :)
Hope that clarifies things a bit.
prochac commentedon Dec 20, 2023
@mitchellh that's why I added the link to viper contributors. https://github.com/spf13/viper/graphs/contributors
To add @sagikazarmark some credibility.
He seems legit.
mitchellh commentedon Dec 20, 2023
All good, thanks to both you 😄
prochac commentedon Dec 20, 2023
mitchellh commentedon Dec 20, 2023
I hid your comment, I don't want to offend anyone right now as we're just about to archive this project 😄
sagikazarmark commentedon Dec 21, 2023
@mitchellh are you OK with me sending a message to all open issues and PRs that they may resubmit to the fork?
I pulled in the PRs the seemed to have fixed the most inportant issues, but there are quite a few other valuable contributions there.
mitchellh commentedon Dec 21, 2023
Yes I’m okay with that, thanks for asking
thaJeztah commentedon Dec 22, 2023
Curious if transferring the repository is an option, so that GitHub's redirects lead visitors to the right place, preserve more history such as tickets and pull requests, and go modules to function without "replace" rules for versions of the module before renaming.
I see the other repository is now "ahead" a couple of commits, but the module hasn't been renamed yet, so that may complicate things a bit (this repository's git would probably have to be aligned before that)
thaJeztah commentedon Dec 22, 2023
Ignore me 🙈 I looked at the v1.6.0 tag, which carries the old name, but it was renamed since
11 remaining items
Update module go.opentelemetry.io/collector/exporter/otlphttpexporter…
Update module go.opentelemetry.io/collector/receiver/otlpreceiver to …
Update module go.opentelemetry.io/collector/exporter/otlpexporter to …
Merge upstream v0.96.0 (#13660)
Use github.com/go-viper/mapstructure/v2
Use github.com/go-viper/mapstructure/v2
Use github.com/go-viper/mapstructure/v2
Thiht commentedon Apr 20, 2024
If the change is official, can you add a notice to the README, and maybe archive this repository? The current state of affairs is a bit confusing tbh
sagikazarmark commentedon Jun 2, 2024
I tagged 2.0.0: https://github.com/go-viper/mapstructure/releases/tag/v2.0.0
sagikazarmark commentedon Jun 2, 2024
@mitchellh I can open a PR to add a notice to the readme if you want me to, but it may be better if it comes from you. Let me know which one you prefer.
fix(deps): update module go.opentelemetry.io/collector/receiver to v0…
fix(deps): update module go.opentelemetry.io/collector/pdata to v1.9.0 (
fix(deps): update module go.opentelemetry.io/collector/consumer to v0…
fix(deps): update module go.opentelemetry.io/collector/exporter to v0…
Upstream merge 0.100.x (#42)