search

caxlsx / caxlsx_rails

A Rails plugin to provide templates for the axlsx gem
MIT License
742 stars 84 forks source link

rename to caxlsx_rails #126

Closed OpenCoderX closed 4 years ago

OpenCoderX commented 5 years ago

To keep our naming consistent, should this community version be renamed 'caxlsx_rails'?

straydogstudio commented 5 years ago

I almost did that when we first started the change. I am open to it. @jurriaan @noniq @simi Any thoughts?

simi commented 5 years ago

We should rename everything from axlsx* -> caxlsx* to prevent confusions and get unique gem name.

noniq commented 5 years ago

+1

straydogstudio commented 5 years ago

I will change it and release a new gem.

Currently I am the only owner of these gems on rubygems.org. that probably should not be. Anyone here willing to take that on if I am hit by a truck? I will add you as an owner.

simi commented 5 years ago

Feel free to add me @straydogstudio - https://rubygems.org/profiles/retro.

straydogstudio commented 5 years ago

Thanks @simi. I've added you to caxlsx. I'll add you to caxlsx_rails when it is released.

straydogstudio commented 5 years ago

As a general procedure I will try to get consensus from all four of us before a release, unless there is some mitigating factor that makes it urgent, like releasing a bug.

caifara commented 4 years ago

Great to see this gem come to life again! As it is probably used by many, may I suggest some extra effort in the form of a new release of the old gem with deprecation warnings (like in a post install message)?

noniq commented 4 years ago

Good idea, but I’m not sure if anyone of us has the necessary access rights on Rubygems to publish new versions of axlsx (I definitely don’t).

caifara commented 4 years ago

Sure, but it seems you can publish axlsx_rails gems. So it would be nice to have such an extra release on that gem once you rename it. As caxlsx is a depedency of caxlsx_rails a lot of people will benefit. From a user point-of-view I'm not especially in favor of renaming the gem although I understand why you decided to do so.

straydogstudio commented 4 years ago

Sorry I've not gotten to this. I intend to soon. I am fine doing a release of axlsx_rails that contains deprecations, and then move the same code to caxlsx_rails.

We had to rename axlsx because we had no access to the release on rubygems. That was unfortunate. I don't think it was worth doing in itself. But we are now here. It does have the benefit of making a clean break between the original code and the community code.

Theoretically it is possible to do dual releases of axlsx_rails and caxlsx_rails with the same code. Does anyone have any thoughts on this? I expect it would just be confusing.

OpenCoderX commented 4 years ago

I'm in favor of the clean break to the new gem names. We need to have full control of the build process, including rubygems releases. With the new gems being managed by an org it allows for more redundant maintainers as well as use of all the org tools github provides.

It makes sense to have a final release of the legacy gems where possible, including deprecation notices at runtime and readme notices of the same purpose. We don't have any plans to introduce API breaking changes so asking existing axlsx users to swap gem names is not a deal breaker in my mind.

It also seems that the new org has reinvigorated the community, we have some new contributors (including myself), net wins in all cases.

caifara commented 4 years ago

For what it's worth, I second that: clean break with a last release.

straydogstudio commented 4 years ago

axlsx_rails 0.6.1 released with a deprecation. caxlsx_rails 0.6.2 released. The github repo has been renamed to caxlsx/caxlsx_rails; the old address will redirect to the new. An initial renaming done in the readme, etc. We can keep an eye out for other locations.