On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Are there any points on this I might missed? ;) As it appears the branch is already working well (beside the mentioned points) I think we should do a release just in front of. In case of there are major issues after merging to trunk, a maintenance release without feature can be build up using a commit before submitting the changes inside a new branch. Just in case of.
Cheers, Frank