Add Tag to Branch with composer.json? about adldap

[strebl]

I created a tagged version a while ago: https://packagist.org/packages/strebl/adldap

[samwilson]

Have a read through #4 — the chances seem to small that anything's going to be done to fix the situation.

@stevebauman is also maintaining a fork; see #4 (comment) In the interests of slightly reducing the already-prevalent fragmentation, I'd recommend using that one.

[samwilson]

(Oh, and I'd say this issue could be closed as a dupe of #4.)

[stevebauman]

Yea to be honest, this repository is definitely abandoned in my opinion. The main packagist author has been inactive from github for close to a year and rich2k has been inactive for well over a year.

I'd suggest using a fork that's available on packagist and verify the authors recent commits so you know it'll be in the hands of someone who is active in the community.

Personally, I'm going to start combing through this giant mess of forks and start merging in valid fixes, and hopefully create a better adLDAP from it.

[strebl]

@stevebauman 👍
As soon as you are ready i'll abandon my package and replace it with yours!
I just didn't see your package. Maybe because the name is different.

I was going to add some functionality to my package. But if you'll maintain your repo, I'll create the PRs on your repo!?

[stevebauman]

@strebl That's no problem, and I'll be starting the merges shortly, I'm just cleaning up all of the classes right now and I'll be all set. Feel free to create issues and PRs on my forked repo!

[astorm]

@stevebauman At the risk of volunteering someone for extra work -- it'd be great if your repository had the same tag history as https://github.com/ztec/adLDAP.git

With that tag history in place there'd be a more compelling case for taking over the adldap/adldap packagist name i.e. preserver the current versions, but give current adldap/adldap users the chance to upgrade.

[stevebauman]

@astorm I agree with you, that's a great idea. I'll create a separate branch with the old history and tag the previous releases.

I use this library myself like many of you, and want to continue using and improving it, so please don't hesitate making suggestions and changes that need to be made for the better of the library.

[laurinkeithdavis]

We're using @stevebauman 's version, and I'm all for moving in that direction as well and would be interesting in contributing as well - adLDAP is a critical piece of our operation.

[strebl]

Yeah, the adldap/adldap name would be fantastic.

[stevebauman]

Unfortunately getting the original packagist repository name is a slim to none chance as @ztec has already said he would do this and didn't deliver. Unless there's some way of 'petitioning' the name then I'm not sure if we can recover it as far as my knowledge goes.

Though I also wanted to say, I'll be able to add other maintainers to this fork as well, hopefully further ensuring adLDAPs future.

[strebl]

@stevebauman Yah, you are right. Maybe it's only me, but I don't like the -fork suffix. It takes some value off of your package.

I'll try my best to help you as good as I can.

[astorm]

@stevebauman Petitioning for the name is sort of what I had in mind -- being able to come to the packagist folks with a backwards compatible repository with recent commits and some interest might fly and/or might get the attention of the folks currently ignoring the other repositories (leading to them merging in fixes)

[ralfbecker]

I'm also maintaining an adLDAP fork for http://www.egroupware.org/ and have (unsuccessful) sent pull requests with important fixes to adLDAP. I'm willing to help maintaining a forked adLDAP, as I have to maintain it anyway. Name-wise I would probably go for adLDAP2, as it makes it immediately clear what to use ;-)

[stevebauman]

@strebl You're right, I don't like the -fork suffix either, and I agree with your reasoning.

@ralfbecker I agree with adLDAP2 as well! I'll go with this.

@astorm If we use the name adLDAP2 as ralf has suggested, then we won't need to recover the previous name. We can keep namespaces the same and work on the classes itself and upgrade the code base as necessary, allowing users to migrate to adLDAP2 without issues.

I've created a new adLDAP2 organization. I'm going to migrate everything over to this repository. Give me a few moments to get everything set up. https://github.com/adLDAP2/adLDAP2

[samwilson]

Thanks @stevebauman! This is terrific.

[astorm]

@stevebauman Again, I'm always hesitant to volunteer extra work -- but a tag compatible version means we might be able to convince the packagist folks to hand over adldap/adldap to the new repository -- which would be a win for the 14,000ish folks who've installed the library and (more importantly) help prevent a lot of confusion from folks who are just installing the first thing they see.

[stevebauman]

@astorm Has this been done before? I've never experienced this sort of issue. Do I need to contact packagist personally once I've completed making tag compatible versions?

[strebl]

Does anyone know if there is a way to compare my adldap fork to the adldap2 repo using github or another solution?

[ChadSikorra]

Has anyone tried to actually email Rich or Scott to see if they really have abandoned their work on this library? It looks like they do have their email addresses on the front page and it appears like they did mean to release a 5.0.0 version at some point.

[stevebauman]

Both Rich and Scott have both left the adLDAP organization they created, so presumably no, I don't think they're interested in working on it anymore.

[ChadSikorra]

Good catch. I didn't even notice that.

[wunc]

@stevebauman Dude, thanks so much for this! I had forked adLDAP just to get some customizations that I needed for our org: authenticating with something other than samaccountname or guid, better search options. Glad to see someone willing to reinvigorate the project.

[stevebauman]

No problem! If you're able to help definitely send some pulls my way. The more community and help, the better.