Trac 0.10rc1 Released
Jonas Borgström
==============================
September 22, 2006
We're happy to announce the Trac 0.10rc1 release, available from:
http://trac.edgewall.org/wiki/TracDownload
This is a release candidate, which means that the Trac developers feel
that this release is ready for production use, so we encourage people to
test this release thoroughly. If no serious bugs are found the final
stable 0.10 release will be released on Monday.
For questions, comments and user discussions, please use the Trac mailing
list. List information, subscription and archive available at:
http://trac.edgewall.org/wiki/MailingList
User visible changes
====================
Advanced diff support
---------------------
The TracRevisionLog view can now be used to select two arbitrary
revisions of a given path in the repository and see the differences
between them, in the familiar TracChangeset view.
A related change is the possibility to navigate through a sequence of
restricted changesets. A restricted changeset is the subset of changes
within a changeset inside a given directory. One can easily start
navigating such a sequence by following the new Last Change navigation
link present for the currently browsed path.
It's now also possible to compare two arbitrary paths at any revision.
This can be used to check the differences between a tagged version and
trunk, or to review the set of differences between two branches.
Other enhancements have been made to the version control subsystem, in
particular the support of scoped repositories has been improved. You
should therefore perform a trac-admin resync operation.
InterWiki and InterTrac support
-------------------------------
An InterWiki link can be used to refer to a Wiki page located on another
Wiki system, and by extension, to any object located on any other Web
site, as long as simple URL mapping is possible.
An InterTrac link can be used for referring to a Trac resource (Wiki
page, changeset, ticket, ...) on an other Trac environment. This makes it
easier to work with multiple separate projects, and seamlessly refer to
resources from one Trac to another.
Improved modularity
-------------------
Trac now supports database and version control backends as third-party
plugins.
It is now easier to add support for new database backends. In addition to
the already existing support for SQLite and PostgreSQL, Trac now features
experimental support for the MySQL database.
As for the version control systems, Trac still features best of breed
Subversion support, but the Subversion bindings and libraries are no
longer mandatory for using Trac itself. Other version control systems can
be supported by external plugins.
Improved notification system
----------------------------
The encoding for emails sent out by Trac can now be configured. This may
decrease email size and can avoid useless encoding for western languages
that make some touchy SMTP servers bounce the notifications.
Support for local network installations using local email addresses
(addresses without a domain name) and a configurable default domain name
has been added, as well as support for both visible and blind carbon
copies.
Support for spam protection
---------------------------
Trac now provides extension point that allow plugins to intercept content
submissions, which can be used to filter out spam. One plugin that does
this is the SpamFilter plugin, which is available as a separate package:
http://trac.edgewall.org/wiki/SpamFilter
This plugin implements a number of different strategies for testing
content, such as regular expression matching, IP blacklisting, and
Akismet queries.
WSGI used as web server protocol
--------------------------------
Trac now uses WSGI (the "Python Web Server Gateway Interface")
internally. While Trac continues to provide builtin support for CGI,
FastCGI and mod_python, as well as the standalone server "tracd", you can
now take advantage of the WSGI support to use Trac in other setups, such
as Twisted, Paste, SCGI, or ISAPI.
Lots of minor improvements
--------------------------
To the Wiki syntax
Numerous improvements have been made in the WikiFormatting syntax:
* Headings can optionally be given explicit id.
* MoinMoin ["internal free link"] syntax is now supported.
* Introduced citation syntax for the Wiki (e-mail style).
* Added more robust parsing and formatting of Wiki lists and robust
coupling of lists and quotes.
* Improved the way external links are displayed.
* Lots of new ways to refer to specific repository views (diff:from//
to, log:, [x:y], rx:y)
* htdocs:, useful for referring to local resources in TracStandalone
* MoinMoin-style syntax for description lists
* Removed support for direct embedding of images using links: use the
[[Image]] macro instead.
To the Wiki subsystem
* Quicker access to last change on a page and better navigation in the
page history
* Preview the change comment before saving a change and display the
change comment when viewing a specific version of a page. This
hopefully will encourage authors to document their changes!
To the Ticket subsystem
* Possibility to Reply to ticket description and changes
* Export individual ticket data in CSV or RSS format
Developer-visible changes
=========================
unicode everywhere
------------------
Trac used to handle text content by using str objects, in which Unicode
characters were represented using UTF-8 encoding. This lead to various
problems with most non-western languages. We now use the dedicated
unicode datatype to consistently handle text written in any language. See
also TracDev/UnicodeGuidelines.
Better way to programmatically generate HTML fragments
------------------------------------------------------
Trac now provides utility code to programmatically generate HTML
snippets. This can be used in the various places where Trac expects
plugins to return small fragments of HTML bypassing the template system.
These utilities can be found in the trac.util.html module.
Unit test framework for email notifications
-------------------------------------------
Email notifications can now be validated; unit tests include a private
SMTP server and helper methods to extract and decode email data.
Internal API changes
--------------------
A detailed view of the API changes since 0.9.x can be found in TracDev/
ApiChanges/0.10.
Acknowledgements
================
Many thanks to the growing number of people who have, and continue to,
support the project. Also our thanks to all people providing feedback and
bug reports that helps us make Trac better, easier to use and more
effective.
Without your invaluable help, Trac would not evolve. Thank you all.
Finally, we offer hope that Trac will prove itself useful to like-minded
programmers around the world, and that this release will prove an
improvement over the last version.
Please let us know. :-)
/The Trac Team http://trac.edgewall.org/
Ilias Lazaridis
> Release Notes for Trac 0.10rc1
> ==============================
> September 22, 2006
>
> We're happy to announce the Trac 0.10rc1 release, available from:
>
> http://trac.edgewall.org/wiki/TracDownload
>
> This is a release candidate, which means that the Trac developers feel
> that this release is ready for production use, so we encourage people to
> test this release thoroughly. If no serious bugs are found the final
> stable 0.10 release will be released on Monday.
Could this 3 day period (which includes a weekend) possibly be extended
e.g. till Thursday, 28th Sep.? I like to do some tests, too, but can
start testing only tomorrow.
-
btw: Release Date 29th of September would be the last working day of the
3rd Quarter 2006.
Possibly this could be used to declare fixed releases days, e.g.:
0.11 for last working-day of 4th Quarter 2006.
0.11 would _focus_ on the genshi-migration, but would include everything
other functionality (e.g. workflow) which could be stabelized in the
development branches/sandboxes.
this could follow e.g. the "pre" milestone-scheme suggested by C. Boos:
"Now, rather than post-pone all the 0.11 features to 0.12, we could
think about creating intermediate milestones, 0.11pre1, 0.11pre2 etc.
which will be "feature" milestones, e.g. 0.11pre1 would be "0.10 +
genshi", 0.11pre2 would be the integration of WorkFlow, 0.11pre3
migration to setuptools, etc."
http://groups.google.com/group/trac-dev/msg/6b253d55c9588fd3
> For questions, comments and user discussions, please use the Trac mailing
> list. List information, subscription and archive available at:
>
> http://trac.edgewall.org/wiki/MailingList
...
.
Jonas Borgström
Ilias Lazaridis wrote:
*snip*
>
> Could this 3 day period (which includes a weekend) possibly be extended
> e.g. till Thursday, 28th Sep.? I like to do some tests, too, but can
> start testing only tomorrow.
>
release was available for testing for a long time, and rc1 contains
only a few changes since then, I think we're good.
However if anybody finds a serious bug we will be able to release
0.10.1 fairly quickly...
Cheers,
Jonas
Ilias Lazaridis
>
> Ilias Lazaridis wrote:
> *snip*
>> Could this 3 day period (which includes a weekend) possibly be extended
>> e.g. till Thursday, 28th Sep.? I like to do some tests, too, but can
>> start testing only tomorrow.
>>
> No, it's too late to move the release date now.
why?
you wrote:
"so we encourage people to test this release thoroughly. If no serious
bugs are found the final stable 0.10 release will be released on Monday."
So, if a serious bug is uncovered, the release will be delayed anyway.
> However since the beta1
> release was available for testing for a long time, and rc1 contains
> only a few changes since then, I think we're good.
> However if anybody finds a serious bug we will be able to release
> 0.10.1 fairly quickly...
Sorry, but I find this _very_ ungentle from this project.
Do you publish a Release Candidate just for having published a release
candidate? For sure there are several people which will not even notice
this 3-day rc.
Please rethink this.
.
Emmanuel Blot
People who wished to test the project had time to do so (many users
are running Trac from the trunk for a long time). Most of the tests
have been done before beta and rc1 anyway.
Let's stop delaying this release. It has been delayed for too long.
Cheers,
Manu
Ilias Lazaridis
>> Sorry, but I find this _very_ ungentle from this project.
>
> People who wished to test the project had time to do so (many users
> are running Trac from the trunk for a long time).
ok, sounds good.
> Most of the tests have been done before beta and rc1 anyway.
>
> Let's stop delaying this release. It has been delayed for too long.
Ok, it seems it was tested thoroughly.
(I am myself a little bit happy that you keep the release-date! would
like to see this 0.10 thing)
.
Manuzhai
> (I am myself a little bit happy that you keep the release-date! would
> like to see this 0.10 thing)
I strictly like it because there'll be fewer people bugging the list
with obsolete Trac problems. ;) I run trunk anyway.
Regards,
Manuzhai
Andres Salomon
A *lot* of people were running trunk for 0.10 features, it seems. A lot
of people who shouldn't have been.
I'd personally love to see time-based releases, or at least
freeze-points. That is, come Jan 1, 0.11 goes into feature freeze
regardless of any unmerged features that people haven't had time to work
on.
Christian Boos
> ...
> This is a release candidate, which means that the Trac developers feel
> that this release is ready for production use, so we encourage people to
> test this release thoroughly. If no serious bugs are found the final
> stable 0.10 release will be released on Monday.
>
I propose that we delay 0.10 for one more day or two.
Now (Monday morning in Europe), we're only starting to see feedback on
the rc1.
There's already one that I consider to be critical and which is maybe
worth some more testing (#3778).
Others, like #3781 are the kind of polishing that can be quickly done
and that a "stable" release would deserve.
-- Christian
Jonas Borgström
Christian Boos wrote:
> I propose that we delay 0.10 for one more day or two.
> Now (Monday morning in Europe), we're only starting to see feedback on
> the rc1.
> There's already one that I consider to be critical and which is maybe
> worth some more testing (#3778).
> Others, like #3781 are the kind of polishing that can be quickly done
> and that a "stable" release would deserve.
Yeah, it looks like we might have to delay the release a day or two
after all. since among other things the proposed patch for #3378 hasn't
yet been verified by the reporter, and as far as I can tell not been
tested on all database backends.
I guess we could wait with this fix until 0.10.1, but in the past we
have tried to avoid changing the db schema on the stable branch.
Cheers,
Jonas
Christian Boos
> Christian Boos wrote:
>
>> I propose that we delay 0.10 for one more day or two.
>> Now (Monday morning in Europe), we're only starting to see feedback on
>> the rc1.
>> There's already one that I consider to be critical and which is maybe
>> worth some more testing (#3778).
>> Others, like #3781 are the kind of polishing that can be quickly done
>> and that a "stable" release would deserve.
>>
>
> Yeah, it looks like we might have to delay the release a day or two
> after all. since among other things the proposed patch for #3378 hasn't
> yet been verified by the reporter, and as far as I can tell not been
> tested on all database backends.
>
So far I tested it with pysqlite (new env. + ugprade), postgres (only
upgrade) and mysql (only new env), but only to see that everything still
works, as I didn't have myself an error before the upgrade.
On the mysql case, I think this could also solve #3676, as having
PRIMARY KEY also enforces a UNIQUE constraints which can't currently be
guaranteed if we truncate the paths...
> I guess we could wait with this fix until 0.10.1, but in the past we
> have tried to avoid changing the db schema on the stable branch.
>
Yep, that's what I was thinking too, so better fix this now if we can.
-- Christian