Re: [ANNOUNCE] Apache Qpid Proton 0.10 released
On 17/08/15 21:57 +0100, Robbie Gemmell wrote: On 17 August 2015 at 21:11, Flavio Percoco wrote: [snip] Is that something we can change in qpid-proton ? I'm entirely on board personally with including the extra digit all the time (and actually using it to do more regular point releases; when I did 0.9.1 that was really the first time any of the components have ever had one). I have been using x.y.z format versions for the JMS client releases from the start for precisely the reasons you covered, so a thumbs up from me. Sounds great to me. I'd assume it's not "fixable" for 0.10, is it? If it can be done for 0.10, I'd be happy to see it happening. Otherwise, I guess we should just keep it in mind for 0.11. Cheers, Flavio -- @flaper87 Flavio Percoco pgpgGLJiEusFD.pgp Description: PGP signature
Re: [ANNOUNCE] Apache Qpid Proton 0.10 released
On 15/08/15 19:14 +0100, Robbie Gemmell wrote: The Apache Qpid community is pleased to announce the immediate availability of Apache Qpid Proton 0.10. Qpid Proton is an AMQP 1.0 messaging library. It can be used in a wide range of messaging applications including brokers, clients, routers, bridges, proxies, and more. This release incorporates a number of defect fixes and enhancements, including Python 3 support for for the Python bidings and a new SASL API and optional cyrus-sasl integration for Proton-C. Release notes are available at: http://qpid.apache.org/releases/qpid-proton-0.10/release-notes.html Outsider question: Is there a reason why 0.10 is used rather than 0.10.0? I believe sticking to 3-digit versions and keep it consistent would make supporting scripts, bindings and even packages easier since they would not have to care about these 2-to-3 digit changes. Is that something we can change in qpid-proton ? Flavio The release is available now from our website: http://qpid.apache.org/download.html Proton-J is also available via Maven Central: http://qpid.apache.org/maven.html Thanks to all involved. Robbie -- @flaper87 Flavio Percoco pgpfCzRf1f9SZ.pgp Description: PGP signature
Re: [VOTE] Release Qpid Proton 0.10 (RC3)
+1 I tested the python bindings. Built the buindings through cmake and ran tests. I also ran tox and tested the pip install process. It seems to work as expected. Thanks On 11/08/15 21:08 +0100, Robbie Gemmell wrote: Hi all, I have put up a third cut for 0.10, please test it and vote accordingly. Since RC2 there have been fixes for PROTON-978, PROTON-975, and PROTON-899. The release archive and sig/checksums can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-rc3/ Maven artifacts for the Java bits can be found in a temporary staging repo at: https://repository.apache.org/content/repositories/orgapacheqpid-1042 It is tagged as 0.10-rc3. You may need to fetch the tags explicitly to see it, e.g: "git fetch --tags" Regards, Robbie -- @flaper87 Flavio Percoco pgpFRjXdga8Vp.pgp Description: PGP signature
Re: Can we release proton 0.10? Can we add Py3K to that release?
On 23/06/15 11:29 +0100, Robbie Gemmell wrote: On 22 June 2015 at 19:14, aconway wrote: On Tue, 2015-06-16 at 23:38 -0400, Rafael Schloming wrote: I'd like to get the proton-j-reactor branch into 0.10 also. It should be ready soon, so if py3k can be sorted and merged in a similar timeframe we could target a release for the end of the month. The C++ and Go bindings are also close to ready. I would not advocate delaying the release just for them if there are already key features that people are asking for, but if we can get them ready in time it would be good to include them. If they are ready I would say include them. If they aren't, then I release without them and do another release once they are. I'd say the same for most large additions if they aren't needed to complete / round out other changes already made for the next release. I think we tend to be guilty of putting everything in together, resulting in a big release that can then drag on a bit, making it more difficult to respond quickly if the need arises, which in turn makes us want to complete the cycle by including yet more stuff into the release just to avoid it having to wait around for a while until the following release happens. +1 to the above and since I'm replying to this email, I'll take the chance to ask where we are at with the release :) We're at the end of juno which, IIRC, is the estimated date that we picked at the beginning of this thread as a good release time. Can we get 0.10 out ? Thanks everyone, looking forward to the 0.10 release, Flavio Robbie --Rafael On Tue, Jun 16, 2015 at 3:32 PM, Flavio Percoco wrote: > Greetings, > > I've been looking with great pleasure all the progress happening in > proton lately and I was wondering whether it'd be possible to have > an > 0.10 release cut soon. > > There are some bugfixes I'm personally interested in but also some > important changes (specifically in the python bindings) that will > make > consuming proton easier for users (OpenStack among those). > > Is there a chance for the above to happen any time soon? > > Can I push my request a bit further and ask for the py3k code to be > merged as well? > > All the above are key pieces to make proton more consumable and > allow > for services like OpenStack to fully adopt it. > > Thanks, > Flavio > > -- > @flaper87 > Flavio Percoco > -- @flaper87 Flavio Percoco pgpaDK8Rw4Azz.pgp Description: PGP signature
Re: Can we release proton 0.10? Can we add Py3K to that release?
On 22/06/15 14:14 -0400, aconway wrote: On Tue, 2015-06-16 at 23:38 -0400, Rafael Schloming wrote: I'd like to get the proton-j-reactor branch into 0.10 also. It should be ready soon, so if py3k can be sorted and merged in a similar timeframe we could target a release for the end of the month. The C++ and Go bindings are also close to ready. I would not advocate delaying the release just for them if there are already key features that people are asking for, but if we can get them ready in time it would be good to include them. I think there's no harm on waiting 'til next week but it'd be nice to get it out by the end of June. Does the above sound sane? Cheers, Flavio --Rafael On Tue, Jun 16, 2015 at 3:32 PM, Flavio Percoco wrote: > Greetings, > > I've been looking with great pleasure all the progress happening in > proton lately and I was wondering whether it'd be possible to have > an > 0.10 release cut soon. > > There are some bugfixes I'm personally interested in but also some > important changes (specifically in the python bindings) that will > make > consuming proton easier for users (OpenStack among those). > > Is there a chance for the above to happen any time soon? > > Can I push my request a bit further and ask for the py3k code to be > merged as well? > > All the above are key pieces to make proton more consumable and > allow > for services like OpenStack to fully adopt it. > > Thanks, > Flavio > > -- > @flaper87 > Flavio Percoco > -- @flaper87 Flavio Percoco pgpg3NXXRkRWh.pgp Description: PGP signature
Re: Can we release proton 0.10? Can we add Py3K to that release?
On 17/06/15 08:19 -0400, Ken Giusti wrote: Re: py3k - I think we're really close - I've rebased my local kgiusti-python3 to latest trunk, and have a few bugs to sort out but I don't think that will take too long. The one missing 'feature' I had planned for py3: modify the tox tests to automagically run under all installed versions of python. But this all should be do-able before the end of the month IMHO. Just to follow up on this thread and bring up the latest news. The python 3 support has been merged in the master branch. This was one of the things we were waiting for to issue a release. Rafael, do you think the proton-j-reactor work will be able to hit master soon? It'd be lovely to have all these released asap (but first lets give python3 at least a week to be tested in master). Cheers, Flavio - Original Message - From: "Flavio Percoco" To: "Rafael Schloming" Cc: users@qpid.apache.org, pro...@qpid.apache.org Sent: Wednesday, June 17, 2015 2:20:09 AM Subject: Re: Can we release proton 0.10? Can we add Py3K to that release? On 16/06/15 23:38 -0400, Rafael Schloming wrote: >I'd like to get the proton-j-reactor branch into 0.10 also. It should be >ready >soon, so if py3k can be sorted and merged in a similar timeframe we could >target a release for the end of the month. This sounds awesome, I think it can be done based on the latest email from Ken about Py3K. Thanks, Flavio > >--Rafael > >On Tue, Jun 16, 2015 at 3:32 PM, Flavio Percoco wrote: > >Greetings, > >I've been looking with great pleasure all the progress happening in >proton lately and I was wondering whether it'd be possible to have an >0.10 release cut soon. > >There are some bugfixes I'm personally interested in but also some >important changes (specifically in the python bindings) that will make >consuming proton easier for users (OpenStack among those). > >Is there a chance for the above to happen any time soon? > >Can I push my request a bit further and ask for the py3k code to be >merged as well? > >All the above are key pieces to make proton more consumable and allow >for services like OpenStack to fully adopt it. > >Thanks, >Flavio > >-- >@flaper87 >Flavio Percoco > > -- @flaper87 Flavio Percoco -- -K -- @flaper87 Flavio Percoco pgpBBEUTsTbuo.pgp Description: PGP signature
Re: Can we release proton 0.10? Can we add Py3K to that release?
On 16/06/15 23:38 -0400, Rafael Schloming wrote: I'd like to get the proton-j-reactor branch into 0.10 also. It should be ready soon, so if py3k can be sorted and merged in a similar timeframe we could target a release for the end of the month. This sounds awesome, I think it can be done based on the latest email from Ken about Py3K. Thanks, Flavio --Rafael On Tue, Jun 16, 2015 at 3:32 PM, Flavio Percoco wrote: Greetings, I've been looking with great pleasure all the progress happening in proton lately and I was wondering whether it'd be possible to have an 0.10 release cut soon. There are some bugfixes I'm personally interested in but also some important changes (specifically in the python bindings) that will make consuming proton easier for users (OpenStack among those). Is there a chance for the above to happen any time soon? Can I push my request a bit further and ask for the py3k code to be merged as well? All the above are key pieces to make proton more consumable and allow for services like OpenStack to fully adopt it. Thanks, Flavio -- @flaper87 Flavio Percoco -- @flaper87 Flavio Percoco pgpYE0rms99KH.pgp Description: PGP signature
Can we release proton 0.10? Can we add Py3K to that release?
Greetings, I've been looking with great pleasure all the progress happening in proton lately and I was wondering whether it'd be possible to have an 0.10 release cut soon. There are some bugfixes I'm personally interested in but also some important changes (specifically in the python bindings) that will make consuming proton easier for users (OpenStack among those). Is there a chance for the above to happen any time soon? Can I push my request a bit further and ask for the py3k code to be merged as well? All the above are key pieces to make proton more consumable and allow for services like OpenStack to fully adopt it. Thanks, Flavio -- @flaper87 Flavio Percoco pgpNN_84fmC5d.pgp Description: PGP signature
Re: Python 3 port is 'done'
On 30/04/15 11:08 -0400, Ken Giusti wrote: - Original Message - From: "Ken Giusti" To: pro...@qpid.apache.org Cc: users@qpid.apache.org Sent: Thursday, April 30, 2015 9:18:26 AM Subject: Re: Python 3 port is 'done' - Original Message - > From: "Rafael Schloming" > To: pro...@qpid.apache.org > Sent: Thursday, April 30, 2015 9:00:14 AM > Subject: Re: Python 3 port is 'done' > > On Thu, Apr 30, 2015 at 8:35 AM, Ken Giusti wrote: > > > > > > > - Original Message - > > > From: "Rafael Schloming" > > > To: pro...@qpid.apache.org > > > Sent: Wednesday, April 29, 2015 4:24:09 PM > > > Subject: Re: Python 3 port is 'done' > > > > > > What happens when I run make test and I have both python2 and python3 > > > installed on my system? Do the tests run once under each version or > > > does > > > one of the versions 'win'? > > > > At this point it only runs on the 'default' version - whatever > > /usr/bin/python resolves to. > > > > I like the idea of having it run on all installed python versions, but I > > haven't explored how to do that yet. > > > > I've been using virtualenv [1] to switch between the two versions of > > python I have installed on my development station. Tox [2] is probably > > the > > best approach to enable testing against multiple python environments. > > > > I'll look into tox a bit and see what I can come up with. > > > > My system comes with both python and python3 on my path. Just running > python3 manually on proton/tests/proton-test will run it with the python3 > interpreter. I don't know how standard this setup is (I'm running stock > fedora 20), but it would be pretty easy to do a check in cmake and run the > tests using python3 if present. > > I'm also a fan of running both python versions if present, but I also don't > want to double the time it takes to run through the tests. Given that we > are mostly looking for syntactic incompatibilities in the wrapper code > here, I wonder if it would be sufficient to run a subset of the tests that > is likely to give us good coverage on the wrapper code but doesn't bother > trying to exercise all the C code twice. Obviously if this proves > insufficient we could expand the subset. Oh yeah - totally agreed. Just some smaller subset of python-test would make me happy. I found most problems were covered by the engine, codec, transport test modules btw. If that's all we need, then simply running python3 directly on the unit tests makes the most sense. Ah, turns out the 'hard problem' is not running the tests, but building both py2 and py3 binaries from the c-wrapper. Totally different include and link libraries and different install paths. Cmake doesn't appear to directly support this - it only resolves to one instance of python, though that instance can be configured. But nowhere does it provide a list of available pythons - we'd have to script that ourselves. Once we have that list, we should use the setup.py script to build/install the language specific module. setup.py already handles swig, so simply invoking setup.py for each available python interpreter would do all the heavy lifting. thoughts? I'd probably have cmake/ctest running things for the default python and leave the rest of the tests to `tox` as it'll create the required virtual environments for each supported version. This would be my preference. That said, you could also have cmake building the bindings for each version in different paths. This will complicate the cmake step further and I presonally think this belongs to the bindings, Cheers, Flavio > > --Rafael > -- -K -- -K -- @flaper87 Flavio Percoco pgpMwijdjd5aO.pgp Description: PGP signature
