search

pods-framework / pods

The Pods Framework is a Content Development Framework for WordPress - It lets you create and extend content types that can be used for any project. Add fields of various types we've built in, or add your own with custom inputs, you have total control.
https://pods.io/
GNU General Public License v2.0
1.07k stars 264 forks source link

Un-abandon the Packagist entry #5030

Closed GaryJones closed 6 years ago

GaryJones commented 6 years ago

Describe the bug https://packagist.org/packages/pods-framework/pods is marked as Abandoned, which doesn't appear to be the case.

Expected behavior The package not to be marked as abandoned, so that folks can use it as a dependency to their site, and not have it be flagged in Composer:

screenshot 2018-06-10 22 37 47

quasel commented 6 years ago

Confirmed ;)

quasel commented 6 years ago

workaround #4774

pglewis commented 6 years ago

I'm not really a composer user so I'm wondering if there is an advantage to doing this rather than just cloning the Pods repo via git. Maintaining the composer package is One More Thing(TM) so I'm looking to understand the value of doing so.

GaryJones commented 6 years ago

There are many advantages to using Composer but version resolution is the biggest, since it's a dependency manager.

There's really nothing to maintain - just tell Packagist the package is not abandoned, and ensure that it's hooked up to auto-update when a new release is made here.

For me, I have a site repo, which is basically a composer.json, and a few other basic files (.editorconfig, favicon.ico, .gitignore etc.). In that, I list my dependencies, such as WPStarter (others prefer the more popular Bedrock, and then my plugins such as Yoast SEO, Pods, and a theme like Genesis.

Upon composer install, these dependencies are pulled from Packagist (for package that already support Composer), WPackagist (for free plugins that don't support Composer), and a private SatisPress install (for premium plugins and themes). The install process puts everything into the correct directory, and sets up .env files for all of the environment variables.

I'd super strongly urge that Composer support be maintained. You may not use it, but it's powerful and well used within the community.

pglewis commented 6 years ago

I'd super strongly urge that Composer support be maintained. You may not use it, but it's powerful and well used within the community.

It ain't that tough a sell, I was just looking to understand because I was completely ignorant.

pglewis commented 6 years ago

I believe only @sc0ttkclark has the power. I think this is managed via packagist.org and I never even had an account there until today.

sc0ttkclark commented 6 years ago

I thought this was already set up for composer so that’s our bad there. We’ve been using the package.json for years now and thought it just worked.

Will get the status updated.

GaryJones commented 6 years ago

Once you've hooked the accounts, up, there's a grey "Un-abandon" button that needs to be selected:

screenshot 2018-09-07 09 12 41

sc0ttkclark commented 6 years ago

They transferred the package to my sc0ttkclark account, I added pglewis as another maintainer too. After review, I can confirm that the versions that pull in are only the tags without 2.x/ and 1.x/ prefixes. As a result, only versions going forward from 2.7.9+ will be available in Packagist, but I doubt that's going to be a problem.

I looked into doing mass renaming of the tags, but it meant that every single 'release' would have to be created for those new tags (it adds the new tag, then removes the old tag) and we'd lose all the changelogs we archived into GitHub there. I think the 2.7.9+ solution will be fine.

I had to archive the release/3.0-pre-cmb2 branch because of a composer package definition error, it's now tagged at https://github.com/pods-framework/pods/releases/tag/archive%2F3.0-pre-cmb2 (for my reference, since I'll be referencing some of this 3.0 stuff for Groups in 2.8)