Hi there, The latest release on the cheeseshop is Py 0.9, from last february. Since the trunk now contains a bugfix I'd like to have, this is a good time to start bugging you guys for a release again. :) What would releasing a new version of py entail? Do you guys maintain a changelog? I just tried to look for one in SVN but I can't find one. I can find a TODO.txt in doc with todo items. Regards, Martijn
Martijn Faassen wrote:
Hi there,
The latest release on the cheeseshop is Py 0.9, from last february. Since the trunk now contains a bugfix I'd like to have, this is a good time to start bugging you guys for a release again. :)
What would releasing a new version of py entail? Do you guys maintain a changelog? I just tried to look for one in SVN but I can't find one. I can find a TODO.txt in doc with todo items.
Regards,
Martijn
The first thing on todo list is to bug holger to find some time for pylib :-) I've got quite a bit pending changes on a branch and would like to have it merged before the release. There are also other things to do (such as rewrite of web reporter) to make things even more cool, but IMHO the main blocker is lack of tutorial/easy-startup on the web page. Cheers, fijal :.
Maciek Fijalkowski wrote:
Martijn Faassen wrote:
The latest release on the cheeseshop is Py 0.9, from last february. Since the trunk now contains a bugfix I'd like to have, this is a good time to start bugging you guys for a release again. :)
What would releasing a new version of py entail? Do you guys maintain a changelog? I just tried to look for one in SVN but I can't find one. I can find a TODO.txt in doc with todo items.
Regards,
Martijn
The first thing on todo list is to bug holger to find some time for pylib :-)
I've got quite a bit pending changes on a branch and would like to have it merged before the release. There are also other things to do (such as rewrite of web reporter) to make things even more cool, but IMHO the main blocker is lack of tutorial/easy-startup on the web
I agree with that :-). page. What's wrong with this page: http://codespeak.net/py/dist/test.html ? I quite liked it when I learned about py.test first. Cheers, Carl Friedrich
On Wed, Nov 07, 2007 at 17:44 +0100, Carl Friedrich Bolz wrote:
Maciek Fijalkowski wrote:
Martijn Faassen wrote:
The latest release on the cheeseshop is Py 0.9, from last february. Since the trunk now contains a bugfix I'd like to have, this is a good time to start bugging you guys for a release again. :)
What would releasing a new version of py entail? Do you guys maintain a changelog? I just tried to look for one in SVN but I can't find one. I can find a TODO.txt in doc with todo items.
Regards,
Martijn
The first thing on todo list is to bug holger to find some time for pylib :-)
I agree with that :-).
me as well ... However, i am still in sabbatical and hardly-online-at-all mode. should we go for a 0.9.1 release by backporting (verbatim, if possible) some bugfixes and their tests from dist/trunk to svn/py/release/0.9.x and then releasing 0.9.1 from it? I think that going for merging Maciej's reporter branch, reviewing accumulated trunk and dist changes is too much - i wouldn't like to tackle it this year (at least if you ask me today). Martijn, a related question: aren't you involved with launchpad? Do you think using it would be benefitial for the py lib and its development/releases? Could you possibly help with setting us up? What do others think about the idea? best & cheers, holger
I've got quite a bit pending changes on a branch and would like to have it merged before the release. There are also other things to do (such as rewrite of web reporter) to make things even more cool, but IMHO the main blocker is lack of tutorial/easy-startup on the web page.
What's wrong with this page: http://codespeak.net/py/dist/test.html ? I quite liked it when I learned about py.test first.
Cheers,
Carl Friedrich _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
-- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77)
Hi there, On Nov 8, 2007 5:40 PM, holger krekel <holger@merlinux.de> wrote: [about a Py release]
should we go for a 0.9.1 release by backporting (verbatim, if possible) some bugfixes and their tests from dist/trunk to svn/py/release/0.9.x and then releasing 0.9.1 from it?
I think that going for merging Maciej's reporter branch, reviewing accumulated trunk and dist changes is too much - i wouldn't like to tackle it this year (at least if you ask me today). best & cheers,
holger
Backporting would be work for people, but might be the most stable way to go about it if you think the trunk contains a lot of destabilizing changes. Does it? This sounds like you should be doing a release more often so that so many changes don't get a chance to accumulate. :)
Martijn, a related question: aren't you involved with launchpad? Do you think using it would be benefitial for the py lib and its development/releases? Could you possibly help with setting us up? What do others think about the idea?
I'm not involved with launchpad at all in any official capacity, I'm just a user. I use it in a couple of projects. I don't recall setting up launchpad project accounts myself but I think it's just a matter of getting a sign-in and requesting a new project, unless there's data to port. I'm not 100% happy about the launchpad user interface; I always keep having to hunt up how to use the issue tracker each time I use it. Roundup was simpler. Kit even released a note for Infrae customers: http://www.infrae.com/products/silva/auxiliary_docs/launchpad_mapping Launchpad does add a lot of planning features and so on but I suspect these need a project of significant size to be very useful. So, if you need an issue tracker and more, Launchpad might be useful. What I'm mostly hoping for myself is that you guys develop a procedure to do some form of regular releases to the cheeseshop so I can get to bugfixes without having to wait an unknown period. :) Regards, Martijn
Martijn Faassen wrote:
Hi there,
On Nov 8, 2007 5:40 PM, holger krekel <holger@merlinux.de> wrote: [about a Py release]
should we go for a 0.9.1 release by backporting (verbatim, if possible) some bugfixes and their tests from dist/trunk to svn/py/release/0.9.x and then releasing 0.9.1 from it?
I think that going for merging Maciej's reporter branch, reviewing accumulated trunk and dist changes is too much - i wouldn't like to tackle it this year (at least if you ask me today).
best & cheers,
holger
Backporting would be work for people, but might be the most stable way to go about it if you think the trunk contains a lot of destabilizing changes. Does it?
This sounds like you should be doing a release more often so that so many changes don't get a chance to accumulate. :)
+1 for 0.9.1 from me. Including all bugfixes & cheesshop entry.
Martijn, a related question: aren't you involved with launchpad? Do you think using it would be benefitial for the py lib and its development/releases? Could you possibly help with setting us up? What do others think about the idea?
I'm not involved with launchpad at all in any official capacity, I'm just a user. I use it in a couple of projects. I don't recall setting up launchpad project accounts myself but I think it's just a matter of getting a sign-in and requesting a new project, unless there's data to port.
I'm not 100% happy about the launchpad user interface; I always keep having to hunt up how to use the issue tracker each time I use it. Roundup was simpler. Kit even released a note for Infrae customers:
http://www.infrae.com/products/silva/auxiliary_docs/launchpad_mapping
Launchpad does add a lot of planning features and so on but I suspect these need a project of significant size to be very useful.
So, if you need an issue tracker and more, Launchpad might be useful. What I'm mostly hoping for myself is that you guys develop a procedure to do some form of regular releases to the cheeseshop so I can get to bugfixes without having to wait an unknown period. :)
Regards,
Martijn
I think the holger point is about decreasing the cost of maintining codespeak for all projects, but that's just my opinion. IMHO we would never like the idea of not being able to do svn commit for everything. :.
participants (4)
-
Carl Friedrich Bolz -
holger krekel -
Maciek Fijalkowski -
Martijn Faassen