Preparing Trac 0.11.6
Christian Boos
As a short follow-up to the mail of yesterday about the release schedule
for 0.12, I'd like to propose that we cut a 0.11.6 release soon. There
are many good reasons for this:
- we're late
- there's a bunch of good stuff in 0.11.6dev (lots of bug fixes,
several performance improvements) [1]
- having this behind us will make it easier to fully focus on 0.12
The only downside is that if we release 0.11.6 now, a bunch of important
issues will be left opened. But as there's no clear action to take for
solving those tickets, postponing the release for an indeterminate
period of time doesn't make much sense and prevents the good stuff to be
delivered to the users.
For example, there's the somewhat hard to reproduce #7785 issue, there
are still performance issues that are not fully understood in some
setups, all things that could possibly warrant a new release once they
get fixed. That's why I've moved them to 0.11.7 for now [2], but
depending on the timing they will eventually be done for a 0.12.x
release in the end (much like 0.10.6dev never got released).
So this evening I went through the remaining tickets with Remy, and we
think we can prepare a release candidate this week-end, with the usual
testing period of one week, next week.
Testers, get ready ;-)
Tim, wake up the build bots!
-- Christian
[1] - http://trac.edgewall.org/query?status=closed&milestone=0.11.6
[2] - http://trac.edgewall.org/query?status=!closed&milestone=0.11.7
W. Martin Borgert
> - there's a bunch of good stuff in 0.11.6dev (lots of bug fixes,
Could you please consider using the patch for #1198 in 0.11.6?
http://trac.edgewall.org/ticket/1198
It applies cleanly, and the Debian package comes by default
with this feature. It's also in 0.12, AFAIK.
rupert....@gmail.com
> Hello,
>
> As a short follow-up to the mail of yesterday about the release schedule
> for 0.12, I'd like to propose that we cut a 0.11.6 release soon. There
> are many good reasons for this:
> - we're late
> - there's a bunch of good stuff in 0.11.6dev (lots of bug fixes,
> several performance improvements) [1]
> - having this behind us will make it easier to fully focus on 0.12
>
> The only downside is that if we release 0.11.6 now, a bunch of important
> issues will be left opened. But as there's no clear action to take for
> solving those tickets, postponing the release for an indeterminate
> period of time doesn't make much sense and prevents the good stuff to be
> delivered to the users.
we try to do a http://opencsw.org solaris package as well, and like
for debian, we'd apreciate if http://trac.edgewall.org/ticket/1198
gets included.
as you mentioned before performance, do you have any experience about
the gain in this release?
rupert.
Christian Boos
> On Nov 13, 11:17 pm, Christian Boos <cb...@neuf.fr> wrote:
>
>> Hello,
>>
>> As a short follow-up to the mail of yesterday about the release schedule
>> for 0.12, I'd like to propose that we cut a 0.11.6 release soon. There
>> are many good reasons for this:
>> - we're late
>> - there's a bunch of good stuff in 0.11.6dev (lots of bug fixes,
>> several performance improvements) [1]
>> - having this behind us will make it easier to fully focus on 0.12
>>
>> The only downside is that if we release 0.11.6 now, a bunch of important
>> issues will be left opened. But as there's no clear action to take for
>> solving those tickets, postponing the release for an indeterminate
>> period of time doesn't make much sense and prevents the good stuff to be
>> delivered to the users.
>>
>
> many thanks for this!!
>
> we try to do a http://opencsw.org solaris package as well, and like
> for debian, we'd apreciate if http://trac.edgewall.org/ticket/1198
> gets included.
>
you. You get to do the testing and all the blame/praise will then be for
you ;-) The problem with that approach is that *if* there's an error
with a Trac installed from your package, when faced to the error report
we'll usually have no way to know if this was from a pristine Trac
install or a patched one, and this could make troubleshooting the
problem very hard. So this is not something I'd advise you to do.
From our side, we're serious about feature freeze for 0.11-stable, so
don't expect any new features there. After 0.11.6, only *critical* fixes
will go on 0.11-stable, if any. The point is that 0.12dev contains a lot
of improvements besides #1198. Why don't you give a try to trunk, if
you're interested in the new features? We're also approaching the 0.12
release date, and as we want to ship it before the end of this year, I'd
say it's about the right time to test it and provide feedback.
For trying out 0.12dev, it should be fairly easy to setup a test
installation; copy your current trac environment, upgrade and test the
copied environment. If you're happy with a particular development
version, you can also promote that to be your new "stable" version. The
point is that we try as hard as we to make trunk stable and usable. If
there's some hazardous and experimental work that gets committed, this
is happening on sandbox branches.
If that helps, I'll document in more details what I'm currently doing on
t.e.o in order to install another virtualenv for 0.12, so that you could
do the same. But it basically boils down to keeping some packages in the
base installation (everything you don't intend to upgrade separately,
like the db bindings, the svn bindings and such), activate the
virtualenv of your choice and install there the specific Trac, Genshi
and plugins with the versions that you need (you can even easy_install
things there). When serving the new environment, make sure you do a
"trac-admin ... deploy <dir>" in a different place than the one used by
your "stable" setup, that your web server is also configured to use this
different <dir>, and specify a different egg-cache location as well. It
should then work ;-)
In the end, let me reiterate that it would be *very* helpful if we could
get more people from Trac-dev to try 0.12dev (not to mention having more
people actually *developing* on trunk...).
> as you mentioned before performance, do you have any experience about
> the gain in this release?
>
"components enabled" cache should improve the startup time a lot when
the environment has lots of plugins, and of course the new eager cursor
and enabled connection pooling will also improve the concurrency
behavior (don't forget to use recent SQLite and PySqlite releases as
well, as this will also contributes greatly to improve performance).
Using Genshi trunk will also give you some performance improvements.
-- Christian