Hello everyone, on behalf of the Cython project team, I'm proud to announce the final release of Cython 0.17. This is another major step forward in the development of the language that will make life easier for a lot of users, rounds up some rough edges of the compiler and adds (preliminary) support for CPython 3.3 and PyPy. It is also the first final release of an implementation of PEP 380 (generator delegation), before it will eventually appear in CPython 3.3. Download: http://cython.org/release/Cython-0.17.tar.gz Release notes: http://wiki.cython.org/ReleaseNotes-0.17 Documentation: http://docs.cython.org/ Major features of this release include: * vastly improved integration with the C++ STL containers http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html#standard-librar... http://docs.cython.org/src/tutorial/strings.html#c-strings * "yield from" delegation between generators (PEP 380) http://www.python.org/dev/peps/pep-0380/ * alpha quality support for PyPy (via cpyext) http://docs.cython.org/src/userguide/pypy.html Several other features and improvements are listed in the release notes: http://wiki.cython.org/ReleaseNotes-0.17 Have fun, Stefan
I'm assuming cython-devel is a proper subset of cython-users, but just wanted to say hooray and thanks for all the work that wen into this release (both new development and pushing the actual release to completion). Is there a plan to announce more broadly? (E.g. python-announce, if you haven't already (moderation adds a bit of latency).) I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts? - Robert On Fri, Aug 31, 2012 at 11:58 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Hello everyone,
on behalf of the Cython project team, I'm proud to announce the final release of Cython 0.17.
This is another major step forward in the development of the language that will make life easier for a lot of users, rounds up some rough edges of the compiler and adds (preliminary) support for CPython 3.3 and PyPy. It is also the first final release of an implementation of PEP 380 (generator delegation), before it will eventually appear in CPython 3.3.
Download: http://cython.org/release/Cython-0.17.tar.gz
Release notes: http://wiki.cython.org/ReleaseNotes-0.17
Documentation: http://docs.cython.org/
Major features of this release include:
* vastly improved integration with the C++ STL containers
http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html#standard-librar...
http://docs.cython.org/src/tutorial/strings.html#c-strings
* "yield from" delegation between generators (PEP 380)
http://www.python.org/dev/peps/pep-0380/
* alpha quality support for PyPy (via cpyext)
http://docs.cython.org/src/userguide/pypy.html
Several other features and improvements are listed in the release notes:
http://wiki.cython.org/ReleaseNotes-0.17
Have fun,
Stefan
Robert Bradshaw, 02.09.2012 06:05:
Is there a plan to announce more broadly? (E.g. python-announce, if you haven't already (moderation adds a bit of latency).)
I had already sent it to the python-announce list and also made an announcement on c.l.py now. :)
I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts?
+1, I'll push the master into the release branch and update the master version to 0.18a0. Regarding 0.18, I won't be able to review any of Mark's changes in his array expressions branch, but I take it that Dag did, so I assume that they should go in right next (after a necessary rebase and maybe some adaptations for the external minivect) and then get consolidated there (if necessary). Looks like they'll make the first big feature for the next release (which in turn makes Mark the perfect "volunteer" for the next release manager ;) ). Stefan
On Sat, Sep 1, 2012 at 11:49 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Robert Bradshaw, 02.09.2012 06:05:
Is there a plan to announce more broadly? (E.g. python-announce, if you haven't already (moderation adds a bit of latency).)
I had already sent it to the python-announce list and also made an announcement on c.l.py now. :)
I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts?
+1, I'll push the master into the release branch and update the master version to 0.18a0.
Perhaps we should use the -pre or -post or -dev marker, as it's not really a marked alpha per say? What about making a 0.17 branch, on which we can do 0.17.1, etc. if necessary. I don't think we're to the point of needing to backport our bugfixes to previous releases, but that will make things clearer. When the 0.18 series is ready, we can make a new branch and work on the release from there (possibly merging in master frequently, but not as a requirement). Alternatively name it bugfix and let it be regularly merged into main, but we can cut minor releases from it. (Release is a bit ambiguous as to its relationship to the other branches).
Regarding 0.18, I won't be able to review any of Mark's changes in his array expressions branch, but I take it that Dag did, so I assume that they should go in right next (after a necessary rebase and maybe some adaptations for the external minivect) and then get consolidated there (if necessary). Looks like they'll make the first big feature for the next release (which in turn makes Mark the perfect "volunteer" for the next release manager ;) ).
I'd be up for that :). - Robert
Robert Bradshaw, 02.09.2012 09:17:
On Sat, Sep 1, 2012 at 11:49 PM, Stefan Behnel wrote:
Robert Bradshaw, 02.09.2012 06:05:
I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts?
+1, I'll push the master into the release branch and update the master version to 0.18a0.
Perhaps we should use the -pre or -post or -dev marker, as it's not really a marked alpha per say?
Right, it's not going to be used in a release, so we don't need it to be parsable. "0.18-pre" it is then.
What about making a 0.17 branch, on which we can do 0.17.1, etc. if necessary. I don't think we're to the point of needing to backport our bugfixes to previous releases, but that will make things clearer. When the 0.18 series is ready, we can make a new branch and work on the release from there (possibly merging in master frequently, but not as a requirement). Alternatively name it bugfix and let it be regularly merged into main, but we can cut minor releases from it. (Release is a bit ambiguous as to its relationship to the other branches).
Ok, "0.17" then. Stefan
Any chance we can tag the official 0.17 release in Github as well? -Brad On Sun, Sep 2, 2012 at 12:40 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Robert Bradshaw, 02.09.2012 09:17:
On Sat, Sep 1, 2012 at 11:49 PM, Stefan Behnel wrote:
Robert Bradshaw, 02.09.2012 06:05:
I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts?
+1, I'll push the master into the release branch and update the master version to 0.18a0.
Perhaps we should use the -pre or -post or -dev marker, as it's not really a marked alpha per say?
Right, it's not going to be used in a release, so we don't need it to be parsable. "0.18-pre" it is then.
What about making a 0.17 branch, on which we can do 0.17.1, etc. if necessary. I don't think we're to the point of needing to backport our bugfixes to previous releases, but that will make things clearer. When the 0.18 series is ready, we can make a new branch and work on the release from there (possibly merging in master frequently, but not as a requirement). Alternatively name it bugfix and let it be regularly merged into main, but we can cut minor releases from it. (Release is a bit ambiguous as to its relationship to the other branches).
Ok, "0.17" then.
Stefan
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
On Tue, 25 Sep 2012, Stefan Behnel wrote:
Any chance we can tag the official 0.17 release in Github as well? BTW, do we use lightweight tags or annotated tags in git? And why?
you should use annotated -a (and/or signed -s, which are annotated) tags you do not use annotated tags: $> git describe upstream/master fatal: No annotated tags can describe 'd0cf23e7dadebdb31064ef8c1fddeaef049622dc'. However, there were unannotated tags: try --tags. $> git describe --tags upstream/master 0.17.1-26-gd0cf23e why should you use them? http://stackoverflow.com/questions/4971746/why-should-i-care-about-lightweig... -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
On Sat, Sep 29, 2012 at 4:08 PM, Yaroslav Halchenko <lists@onerussian.com> wrote:
On Tue, 25 Sep 2012, Stefan Behnel wrote:
Any chance we can tag the official 0.17 release in Github as well? BTW, do we use lightweight tags or annotated tags in git? And why?
you should use annotated -a (and/or signed -s, which are annotated) tags
you do not use annotated tags:
$> git describe upstream/master fatal: No annotated tags can describe 'd0cf23e7dadebdb31064ef8c1fddeaef049622dc'. However, there were unannotated tags: try --tags.
$> git describe --tags upstream/master 0.17.1-26-gd0cf23e
why should you use them?
http://stackoverflow.com/questions/4971746/why-should-i-care-about-lightweig...
I haven't given it much thought before now, but you make a nice point for annotated tags. - Robert
First, congratulations and thanks for keeping such an important project moving forward!! On Sun, Sep 2, 2012 at 12:17 AM, Robert Bradshaw <robertwb@gmail.com> wrote:
What about making a 0.17 branch, on which we can do 0.17.1, etc. if necessary. I don't think we're to the point of needing to backport our bugfixes to previous releases, but that will make things clearer. When the 0.18 series is ready, we can make a new branch and work on the release from there (possibly merging in master frequently, but not as a requirement). Alternatively name it bugfix and let it be regularly merged into main, but we can cut minor releases from it. (Release is a bit ambiguous as to its relationship to the other branches).
In case it's of any use to you guys, feel free to grab our tools for that; we follow precisely that pattern and we're just about to cut a backports-only 0.13.1 release soon: https://github.com/ipython/ipython/blob/master/tools/backport_pr.py Min wrote this tool and from what he tells me, it has really minimized the overhead of keeping a clean backports-only branch available for release. Cheers, f
On Mon, Sep 10, 2012 at 5:41 PM, Fernando Perez <fperez.net@gmail.com> wrote:
First, congratulations and thanks for keeping such an important project moving forward!!
On Sun, Sep 2, 2012 at 12:17 AM, Robert Bradshaw <robertwb@gmail.com> wrote:
What about making a 0.17 branch, on which we can do 0.17.1, etc. if necessary. I don't think we're to the point of needing to backport our bugfixes to previous releases, but that will make things clearer. When the 0.18 series is ready, we can make a new branch and work on the release from there (possibly merging in master frequently, but not as a requirement). Alternatively name it bugfix and let it be regularly merged into main, but we can cut minor releases from it. (Release is a bit ambiguous as to its relationship to the other branches).
In case it's of any use to you guys, feel free to grab our tools for that; we follow precisely that pattern and we're just about to cut a backports-only 0.13.1 release soon:
https://github.com/ipython/ipython/blob/master/tools/backport_pr.py
Min wrote this tool and from what he tells me, it has really minimized the overhead of keeping a clean backports-only branch available for release.
Thanks. Just to clarify your process is to merge the fix into the main branch, and then backport it by creating a new commit (with the above script) for the old releases? - Robert
On Sat, 01 Sep 2012, Stefan Behnel wrote:
Release notes: http://wiki.cython.org/ReleaseNotes-0.17
http://wiki.cython.org/ReleaseHistory references only 0.16 for me ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
On Sun, Sep 16, 2012 at 1:48 PM, Yaroslav Halchenko <lists@onerussian.com> wrote:
On Sat, 01 Sep 2012, Stefan Behnel wrote:
Release notes: http://wiki.cython.org/ReleaseNotes-0.17
http://wiki.cython.org/ReleaseHistory references only 0.16 for me ;-)
Fixed.
participants (5)
-
Bradley M. Froehle -
Fernando Perez -
Robert Bradshaw -
Stefan Behnel -
Yaroslav Halchenko