Edgewall Software
Modify

Opened 12 years ago

Closed 12 years ago

#9661 closed task (fixed)

Release Trac 0.12.1

Reported by: Christian Boos Owned by:
Priority: normal Milestone: 0.12.1
Component: general Version: 0.12-stable
Severity: normal Keywords: release
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (2)

9661-intertrac-r10200.patch (1.4 KB ) - added by Remy Blank 12 years ago.
Fix attachment: and source: intertrac link resolution.
9661-intertrac-2-r10200.patch (1.5 KB ) - added by Remy Blank 12 years ago.
Also recurse into Element items.

Download all attachments as: .zip

Change History (20)

comment:1 by Christian Boos, 12 years ago

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

comment:2 by Remy Blank, 12 years ago

I'm working on it.

comment:3 by Remy Blank, 12 years ago

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

    diff --git a/trac/versioncontrol/svn_authz.py b/trac/versioncontrol/svn_authz.py
    a b class AuthzSourcePolicy(Component):  
    165165                return users & set(usernames) and True or None
    166166
    167167            rm = RepositoryManager(self.env)
    168             repos = rm.get_repository(resource.parent.id)
     168            try:
     169                repos = rm.get_repository(resource.parent.id)
     170            except TracError:
     171                return True # Allow error to be displayed in the repo index
    169172            modules = [resource.parent.id or self.authz_module_name]
    170173            if modules[0]:
    171174                modules.append('')
  • trac/versioncontrol/templates/repository_index.html

    diff --git a/trac/versioncontrol/templates/repository_index.html b/trac/versioncontrol/templates/repository_index.html
    a b  
    1313            <em py:strip="not err">
    1414              <b py:strip="repoinfo.alias != ''">
    1515                <a class="dir" title="View Root Directory"
    16                   href="${href.browser(repos.reponame, order=(order != 'name' and order or None), desc=desc)}">$reponame</a>                                   
     16                  href="${href.browser((repos and (repos.reponame,) or (reponame,))[0],                                                                       
     17                                       order=(order != 'name' and order or None), desc=desc)}">$reponame</a>                                                   
    1718              </b>
    1819            </em>
    1920          </td>

comment:4 by Remy Blank, 12 years ago

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].

comment:5 by Remy Blank, 12 years ago

Patch applied in [10200].

comment:6 by Christian Boos, 12 years ago

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 ;-)

comment:7 by Remy Blank, 12 years ago

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.

in reply to:  7 comment:8 by Christian Boos, 12 years ago

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…

by Remy Blank, 12 years ago

Attachment: 9661-intertrac-r10200.patch added

Fix attachment: and source: intertrac link resolution.

comment:9 by Remy Blank, 12 years ago

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.

comment:10 by Christian Boos, 12 years ago

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/..." />).

in reply to:  10 comment:11 by Remy Blank, 12 years ago

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.

by Remy Blank, 12 years ago

Also recurse into Element items.

comment:12 by Remy Blank, 12 years ago

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

comment:13 by Christian Boos, 12 years ago

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

comment:14 by Remy Blank, 12 years ago

Patch applied in [10201].

comment:15 by Remy Blank, 12 years ago

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.

comment:16 by Remy Blank, 12 years ago

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…

comment:17 by Remy Blank, 12 years ago

False alarm, sorry. I pulled too early.

comment:18 by Christian Boos, 12 years ago

Resolution: fixed
Status: newclosed

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…

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.