Tag new release

[cdekok]

It seems somebody updated the library already to work with guzzle 6 07473e6
Only there hasn't been a new release tagged for almost a year.

[keradus]

There is some bc breaking work needed before new major...

[elstamey]

Can you fix the composer.json and revise the latest release, please? This has been broken for a while.

[keradus]

please elaborate

[elstamey]

In the previous versions, could you apply the change to the guzzle/guzzle name, so we can actually use this package.

[blkperl]

I think the issue @elstamey is describing is this warning from composer.

Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.

The master branch uses guzzlehttp but we need a tag cut or we have to pin to the master branch. Maybe you can backport the change to to the 1.x branch and cut 1.0.2.

[elstamey]

Thank you, @blkperl. That is the issue I was not articulating well.

[jarednova]

It looks like this is updated in the composer.json, but Packagist is still reporting as depending on guzzle/guzzle

[mrailton]

yeah, this needs to be updated as composer is still pulling in guzzle/guzzle instead of guzzlehttp/guzzle

[elstamey]

What is required to get Packagist to update that? I thought it used the composer config.

[mrailton]

Has the new version been tagged in github? from memory you need to tag a new release in github before packagist will show the changes

…

On Sun, Jan 22, 2017 at 6:26 PM, elstamey ***@***.***> wrote: What is required to get Packagist to update that? I thought it used the composer config. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#203 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF1wJayTkCMLntO_wHM7ruJotMq3tm0cks5rU59cgaJpZM4LDRLG> .

[mrailton]

Will answer that myself, there has been no new version for over a year now, last release was https://github.com/satooshi/php-coveralls/releases/tag/v1.0.1 which was released on Jan 20th 2016. This is why packagist is not shipping the change in composer.json. A maintainer needs to create a new release.

[jarednova]

Yeah, this should be as simple as a maintainer tagging a new release for 1.0.2. Packagist should do the rest (but sometimes I've had to go into projects and hit the green "Update" button in Packagist). Can @satooshi or @tmatsuo please help out here? It'd be a quick and easy way to fix issues on a lot of dependent projects

[tmatsuo]

I'm ok tagging 2.0.0 as it is. @keradus WDYT?

[keradus]

our initial idea was to make 2.0 ready to work on windows as well, which requires some work and BC breakers.
sadly, we didn't had time to do it yet :(

[mrailton]

In that case is it possible to at least get tagged to v1.0.2 as would be great to have the update to guzzle as appears quite a few projects use this.

[jarednova]

Yep, v1.0.2 would be all @railto and I (and likely many others) need. 2x is not necessary

[keradus]

sadly, switching guzzle3 to guzzle6 requires changing interfaces of our public class to work with GuzzleHttp\* and not Guzzle\*, thich is a BC breaker.
for that, it cannot be released under 1.x

[tmatsuo]

Yes, so can we release 2.0.0? I'm ok paying some maintenance costs in order to make people happy

[elstamey]

If they changed the name of the package and we can't run it without rolling back to older coveralls, how is it a breaking change? I'm broken already. On Feb 3, 2017 5:57 PM, "Takashi Matsuo" <notifications@github.com> wrote: Yes, so can we release 2.0.0? I'm ok paying some maintenance costs in order to make people happy

[keradus]

@tmatsuo , from what i remember, it was not far to make it compatible with windows. maybe we could focus on that before release? if we won't have time for it then yeah, i think we could release it :(

[glennpratt]

👍 for releasing 2.0 with updated guzzle.

@elstamey you can run dev-master to get the latest or have just have both guzzle projects installed, things still work with the warning.

[elstamey]

@glennpratt The reason that I cannot pull from dev-master is that a package I use, codeclimate, relies on coveralls. It is the one to specify the dependency. I am broken because you are pointing to the name of a package that does not exist. This isn't a case where I can roll back to an older version and fix. I didn't upgrade anything. The package changed it's name.

I truly appreciate the work you are doing on 2.0, but I have no idea when I would begin to use it. And I really don't understand how creating a tagged release of 1.0.2 and pointing it at a valid package name, instead of an invalid one, is a breaking change. 1.0.1 is broken and has no chance of ever working because it points to guzzle/guzzle.

Thank you again for the work you are doing. I really hope you can understand where we are coming from in this request.

[glennpratt]

@elstamey I'm not a contributor here, but I am still using projects that use guzzle/guzzle. It prints a warning on composer install, but does not fail for me.

https://packagist.org/packages/guzzle/guzzle

[keradus]

And I really don't understand how creating a tagged release of 1.0.2 and pointing it at a valid package name

changing FQCN in interface is BC breaker.

1.0.1 is broken and has no chance of ever working because it points to guzzle/guzzle.

1.0.1 is working properly.
proof:
installation: https://travis-ci.org/FriendsOfPHP/PHP-CS-Fixer/jobs/198809989#L274
usage: https://travis-ci.org/FriendsOfPHP/PHP-CS-Fixer/jobs/198809989#L597

[tarlepp]

So what is current status of this ?

[pierredup]

Is there a possibility to set up https://www.appveyor.com/ to run builds against windows? That would make it a bit easier to add more windows compatibility. I would be happy to help out, but don't have a windows machine readily available, so running builds against windows would assist in identifying problem areas

[danmichaelo]

Please just git tag "v2.0.0" for now. When the other stuff is ready, release 3.0.0. Publishing a major release should not be something one would need to contemplate for more half a year!

[jrfnl]

Any updates on this ?
Quite apart from the dependency issues, a tagged release for what is now dev-master would also allow the travis cache to work which would cut down build time for a lot of people.

[localheinz]

Are the maintainers here even alive?

[keradus]

kind of. community don't want help with #203 (comment) :(

[tarlepp]

So why not release 2.0.0 now and then 3.0.0 when those problems are solved ?

[mrailton]

Seems the maintainers don't actually care. Thankfully I no longer need this package.

[glennpratt]

@keradus 2 is just a number, 3 (or whatever number you get to it with) can have Windows work. With a semver like approach, version numbers should work for you, not the other way around.

[keradus]

why not help fixing the problem instead ?

[mrailton]

@keradus We've highlighted how to fix this, and the fix needs to be done by the maintainer, simply tag 1.0.2 on the current master and that's it, simples

[tarlepp]

@keradus community has been waiting this for a really long time... So why don't you want to make community life easier?

[keradus]

@railto, no, it would be bc breaker as mentioned, only line 2, which has bigger agenda
@tarlepp i dont release this app, i'm saying there were bigger release plan for v2

[tarlepp]

ok, i'm thinking to drop this out because of this issue.

[glennpratt]

@keradus what would you like me to do? I'm not a Windows dev. I don't personally use a Windows machine and I haven't run PHP on Windows in over 10 years.

[localheinz]

@glennpratt @keradus

Whatever it takes, I 'm happy to help push this through the door, if possible!

[keradus]

Great to hear at least one of the guys want to help here ;)
@localheinz , app is released as bundle, and that bundle is... versioned to v1 even in v1:
https://github.com/satooshi/php-coveralls/tree/master/src/Satooshi/Bundle/CoverallsV1Bundle

I think we shall change/drop v1 before v2 release, what would you say ?

[keradus]

ping @localheinz , would you mind taking a look at this ?

[keradus]

I took the project. be warned.

[YarekTyshchenko]

sigh. This is a simple issue, with a simple solution:

People rely on older version of guzzle and therefore branch 1.0 of php-coveralls. Lets encourage everyone to progress forward by switching to the new package name and removing warnings from everyone's builds.

In PR #244 I simply change the dependency. Tagging this as 1.0.2 should fix the problem, and not cause any new ones.

[greg-1-anderson]

Anyone who wants to use Symfony 4 will need to use the dev-master release of this project, as the latest stable release (1.0.2 at the time of this writing) still requires guzzle/guzzle, which pins to an older version of symfony/event-dispatcher.

It would be nice if a stable release could be tagged here, so that we had an appropriate semver label for the working commit that is currently the HEAD of dev-master. Calling this version 2.0.0, and bumping up to 3.0.0 later, as previously suggested, would be the ideal course of action.

c.f. Don't fear the 1.0 (also applies to the 2.0.)

[keradus]

probably I still do not have access everywhere, but I did new release. hopefully it gonna work