State of the gem / stale bot too aggressive?
yboulkaid opened this issue · 24 comments
Hi! 👋
We have been heavily using this gem for a couple years now, and it has worked well so far. However, we have been repetitively running into a couple of issues, such as #642 (opened in 2017) and #731.
Looking at the commit history, @parndt has worked on the gem in December 2019, and committed one more time in February 2020. December 2019 is also when the stale bot has been introduced, which closed a number of old issues, of which some are still problematic today.
We are now at a point where we are wondering if this gem is still actively maintained, or if we should consider alternative solutions.
Maintaining an open-source project is hard work, and I am by no means asking that the issues above be fixed. However, I think opening the discussion about this is beneficial for the community, especially people considering using this gem for new projects. Especially since with the stale-bot auto closing issues, a newcomer might think this project is more active than it actually is.
Maybe the members of the globalize organization (@dalpo, @parndt, @scarfacedeb, @simi) could be of help here?
Hi!
It seems that none of us is actively working with any application that uses Globalize, hence the low activity in the repository. And it also seems that @shioyama has taken Globalize's idea further (with pluggable backends, and idea I dropped here a few years ago) and developed Mobility:
https://github.com/shioyama/mobility
I'm not up to date with how production-ready Mobility is, but I'd like us all to check it out and maybe put an official suggestion to go with Mobility. Chris even wrote a migration guide and it seems Mobility is very interface-compatible with Globalize:
https://github.com/shioyama/mobility/wiki/Migrating-from-Globalize
I'm not using globalize as well for years. I'm all in for making this repo "archived" and recommend to move to mobility.
Hi folks! Thanks for the ping. Globalize was the first major open-source project I contributed to so I have some fond attachment to it, but it's also got lots of legacy baggage that I think is hard to support well. That's why I decided to try to build something similar but different, which is what became Mobility.
Mobility solves some of the issues with Globalize (at the cost of doing things differently sometimes), and it's a drop-in replacement for simple cases, but for more tricky stuff (particularly querying) you need to make changes here and there.
Mobility is "production-ready" in the sense that there are many production apps that use it. Technically the latest release is still 0.8.x though. This is because master is targeting an eventual 1.0 release which has some significant changes that I haven't been able to finish tying together.
I will admit though that I don't contribute to Mobility super often right now since I'm really busy with other stuff, and I only use it in one small project. I do intend to support it going forward but since my time is limited I am very strict about not allowing additional complexity or features into the project and only attempting to support existing functionality.
I have mixed feelings about the idea of "archiving" Globalize. On the one hand, Mobility becoming the default replacement brings more attention to it which is nice, but I'm quite worried about all the existing legacy apps using Globalize in weird ways where Mobility will not be a drop-in replacement. I simply can't help all those people migrate, and migrations may not be so simple in some cases.
One "downside" to Mobility is that since it supports a more abstract set of storage backends, the code is less approachable than Globalize's code (read: more metaprogramming). This is a significant issue but it's unavoidable when you try to broaden the use case a gem supports.
So... happy if Mobility helps here 🙂, but it would have to help as-is, since I don't have bandwidth to change it or add to it right now (or necessarily even help people change/add to it, since I'd like to keep it relatively "slim" at the core for reasons stated above).
I haven't used globalize for a couple of years. That made it more difficult to contribute because I'm not encountering the same errors that trouble the globalize users.
I like the idea of modularity and pluggable nature of Mobility. I think it's the best way forward because in theory it may bring more people to use the same solution, instead of hacking around globalize code to support their own backend solutions (e.g. hstore or jsonb column).
I'm happy for it to sit here and be useful for people, and I'm also happy to make the alternative solutions section of the README more prominent: https://github.com/globalize/globalize/tree/8af95a12a0dc76bfdd88762f892dbf5c5a47c6af#alternative-solutions
I have very little time to maintain this software, which I'm no longer using in many projects. We switched Refinery CMS to Mobility in 2018: refinery/refinerycms#3360
I'm happy to merge helpful PRs, including ones that fix bugs that are affecting people but I echo @scarfacedeb in that most of these bugs/errors don't affect me at all so I find it very hard to fix them.
Mobility has been working very well for me for situations where I've needed i18n in Ruby.
Thank you guys for your answers, and for your involvement in this project over the years. It has helped many projects deal with I18n in a sane way :) 🙏
I will be switching over to mobility in the projects that still use globalize now. I can confirm that as @shioyama mentioned, it's mostly a drop-in, the exceptions being mostly around querying.
I like @parndt's suggestion of moving the alternatives section to the top of the readme, maybe with a disclaimer that this gem is not actively maintained and a link to this issue? This way we could have a softer transition than directly archiving the project.
What do you think?
Good idea, will do 👍
Currently Globalize requires Rails < 6.1, is it my understanding that this will not be changed? I actually found this issue because I want to upgrade to Rails 6.1.0-alpha to try new ActiveStorage features.
I am very interested in Mobility but it appears incompatible with PaperTrail, so I feel a bit pushed in a corner and not sure how to proceed 😅
EDIT: I've submitted a PR.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@tomash as was proposed here before the stale bot closed the issue (too fast), would you mind marking the repository as not being actively maintained and highlighting alternatives such as Mobility?
Having personally been "bitten" by the situation (I started using Globalize when it was actually already being abandoned) it'd be great if others encountering the repo could have transparent info about its status. Maybe also remove the term "de-facto standard library"?
Thank you all for your very valued contributions 😊
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Will do, sorry, I haven't checked github for a while.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@tomash here is a kind request to add a deprecation notice to the Globalize README. Please let us know if we can help. Thank you.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hi folks,
I've finally released Mobility 1.0.0.alpha, with a complete re-write of internals (mostly visible in configuration, not actual usage). There will still be a few more pre-release versions before it's stable I'm sure, but I'm finally mostly happy with the internals of the gem and more comfortable with the proposal here to mention Mobility as a Globalize alternative.
Also, because fate loves irony, I'm now maintaining a project at work which uses Globalize and my own (and almost forgotten) easy_globalize_accessors. I've only updated that project to Rails 5.1 so far, so I'm still a bit far from current compatibility with Rails 6+ stuff.
With the README addition I think we can safely close this for now. 🎉 thanks @tomash ❤️ ❤️ ❤️
Mobility 1.0 has been released 🎉