Release Trac 0.12.1

[Christian Boos]

This task ticket is used to coordinate the finalization and testing of the next stable version of Trac, 0.12.1.

We're entering a one week period of testing for the rc1, tagged in [10164]. Packages can be downloaded from TracDownload#LatestReleaseCandidate.

If everything goes well, the release of 0.12.1 will happen the 9th of October, 2010.

Testing

If you'd like to contribute, please fill an entry in the table in TracDev/ReleaseTesting, detailing the configuration(s) you will test, and report the status of your testing in this ticket.

But you can also report glitches found with the rc1 here. If the problem is serious enough, you can also directly create a new ticket against 0.12.1.

[Christian Boos]

As reported on the mailing list this morning, the [[RepositoryIndex]] macro has a few issues:

(default), cboos, cboos.git, cboos.hg, jomae, jomae.git, jomae.hg, mercurial-plugin, mirror, psuter, psuter.git, psuter.hg, rblank, rjollos.git, svn, ticket-links

[Remy Blank]

I'm working on it.

[Remy Blank]

There's an issue in the AuthzSourcePolicy that generates a 500 if a repository is badly configured (i.e. an error should be shown in the repository index). The following patch fixes that, together with a bad link (/browser/undefined) in the repository index for invalid repositories.

(Sorry for the ugly ternary operator hack, but it's on of those cases where you really need a lazily-evaluated ternary operator.)

trac/versioncontrol/svn_authz.py

@@ -165 +165 @@
                 return users & set(usernames) and True or None
 
             rm = RepositoryManager(self.env)
-            repos = rm.get_repository(resource.parent.id)
+            try:
+                repos = rm.get_repository(resource.parent.id)
+            except TracError:
+                return True # Allow error to be displayed in the repo index
             modules = [resource.parent.id or self.authz_module_name]
             if modules[0]:
                 modules.append('')

trac/versioncontrol/templates/repository_index.html

@@ -13 +13 @@
             <em py:strip="not err">
               <b py:strip="repoinfo.alias != ''">
                 <a class="dir" title="View Root Directory"
-                  href="${href.browser(repos.reponame, order=(order != 'name' and order or None), desc=desc)}">$reponame</a>                                   
+                  href="${href.browser((repos and (repos.reponame,) or (reponame,))[0],                                                                        
+                                       order=(order != 'name' and order or None), desc=desc)}">$reponame</a>                                                   
               </b>
             </em>
           </td>

[Remy Blank]

I have finished testing on various combinations of:

• Python 2.4, 2.5, 2.6
• SQLite, PostgreSQL, MySQL
• Linux, OS X, Windows XP, Windows Vista, Windows 7

Except for comment:3, I haven't found any other blocking issues. comment:1 was fixed in [10199].

[Remy Blank]

Patch applied in [10200].

[Christian Boos]

Now that I'm checking the TracGuide for 0.12.1, I remember that we need to fix the InterTrac processing for source: links on trunk (the raw download span which perturbates extract_link). The "optimal" fix (Link element in WikiDom) is not for tomorrow, so for tomorrow we have to find a hack ;-)

[Remy Blank]

For source: links, that issue is only on trunk, AFAIK. However, the same issue is present for attachment: links, on 0.12-stable this time. I have a hack that seems to make it work. Give me a few more minutes.

[Christian Boos]

Replying to rblank:

For source: links, that issue is only on trunk, AFAIK.

Yes, but given that all Tracs in the world have their T: InterTrac links in the TracGuide pointing here…

[Remy Blank]

Fix attachment: and source: intertrac link resolution.

[Remy Blank]

9661-intertrac-r10200.patch​ fixes the issue for me by searching for the first href in the fragment returned by extract_link() instead of assuming that it is an Element.

The final test, however, will be here on t.e.o.

[Christian Boos]

Patch applied on t.e.o, and it seems to work fine.

We don't recurse in Element, but this is OK as our source: or attachments: links are of the form (<a href=".../browser/..." /> <a href=".../export/..." />).

[Remy Blank]

Replying to cboos:

We don't recurse in Element,

Oh, right, Element is a subclass of Fragment, so we actually should. It wouldn't even make the code more complex. Let me try.

[Remy Blank]

Also recurse into Element items.

[Remy Blank]

9661-intertrac-2-r10200.patch​ also recurses into Element items. That should be generic enough for the foreseeable future.

[Christian Boos]

Funny, that's exactly what I come up with when testing initially, so I suppose it's *the* correct way ;-)

[Remy Blank]

Patch applied in [10201].

[Remy Blank]

Release notification sent to trac-dev and trac-users, but I got a bounce from trac-announce because I'm not allowed to post there.

I'm not sure if you update PyPi using python setup.py upload or manually, and I don't have access to Freshmeat. So I'll leave the remaining steps to you:

• Post to trac-announce.
• Update PyPi.
• Update Freshmeat.

[Remy Blank]

Mmh, weird, the Mercurial mirror didn't get the 0.12.1 tag… The 0.12.1rc1 tag is there, so the mechanism should work.

I could add the tag by hand, but I'd rather have it work correctly. Too late for debugging…

[Remy Blank]

False alarm, sorry. I pulled too early.

[Christian Boos]

Well, BitBucket does have a caching problem with the list of Tags (in its pulldown menu), but I suppose this will be refreshed after a while (the repo has the correct information, of course).

Sent the mail this morning to Trac-Announce (Remy, you should ask Jonas to get the permission to post there), updated PyPI (argh), and Freshmeat (submitted twice, hope it will show up only once ;-) ).

Maybe one minor release only every 3 or 4 months is not that bad after all…