[pkg-php-pear] Are you planing to release a Symfony 2.7.9+dfsg-2? (Was: Re: Symfony 2.8)

[David Prévot]

Hi Daniel,

Le 16/02/2016 03:50, Daniel Beyer a écrit :
> On Mon, 2016-02-15 at 10:07 -0400, David Prévot wrote:

>> I pushed some related changes to
>> symfony too (in the wip/random_compat branch),
> 
> Do you intend to release this as 2.7.9+dfsg-2?

I don’t intend to so unless really necessary, but I assume keeping the
2.7 branch open until 2.8 makes it to unstable may be a good idea (I
also assume that we’ll push the first version of 2.8 to experimental, so
it won’t hold further 2.7 update during the NEW processing and will
offer us a change to test and eventually fix the reverse
(build-)dependencies before it gets uploaded to unstable).

> Just asking, since 2.8.2 is on a good way and I'm wondering whether to
> rebase my work against branch master (2.7.9+dfsg-1) or wip/random_compat
> (potential 2.7.9+dfsg-2). Either is fine to me, just let me know.

If all the changes proposed in wip/random_compat make sense for 2.8,
feel free to rebase your work on it. If it doesn’t feel free to reorder
and rebase them in order to rebase your current branch into it (or
simply cherry-pick what you feel is relevant, I don’t mind either way).
I hope I’m understandable, it’s still a bit early for me now…

> I guess changes are good we can release a 2.8.2 by end of this week.

Great. I only had a quick look at what you already done (so might be
mistaken), and wonder if it wouldn’t be easier to stop patching the
”workaround for OR-ed versions”: we could simply let dh_phpcomposer drop
the version (it does that by default when it can’t parse the version),
and restore it’s meaning (the minimal version especially) in d/control
(that means less patching, but more hardcoding in another file, so I’m
not so sure). I don’t know if you already took care of autoload.php.tpl
updating, but I can do it if you don’t want to put your head into it
(like above, it’s a bit like hardcoding information from composer.json
in another file, that’s why I usually handle d/control and
autoload.php.tpl update in the same time).

I add another idea (since I had to put my hand in the build process when
I recently took care of php-symfony-polyfill): we could push
php-symfony-security-{core,csrf,http,*} in the archive and have
php-symfony-security depending on them. We might even push a big
(php-)symfony package depending on all binary packages (using the main
composeer.json file). I’d be happy to work on that if you agree.

Pleas note that I may not have much time to properly look at symfony
before the weekend (so don’t let my suggestions block your update).

Regards

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20160216/57d1a40e/attachment.sig>