Release Trac 0.12.6 / 1.0.2 / 1.1.2

[Ryan J Ollos]

This task ticket is used to coordinate the finalization and testing of the next stable versions of Trac, 0.12.6 and 1.0.2, and the next developer stable version of Trac, 1.1.2.

We'll release a beta1 package first, with the official release to follow within a few weeks.

[Ryan J Ollos]

[bloodhound:BloodhoundReleaseProcess#Preparetherelease] includes steps for signing the release and generating an MD5 checksum. Is anything similar done in the Trac release process? I didn't see any steps in TracDev/ReleaseChecklist.

[Jun Omae]

It doesn't seems we currently sign the released files. But, we've generated md5/sha1 checksums in the past. See TracDownload and *.md5 and *.sha files in ​http://download.edgewall.org/trac/.

[anonymous]

Any news? We are eagerly awaiting for 1.0.2 for more than a year now…

[Ryan J Ollos]

As a follow-on to the question posted in ​gmessage:trac-dev:l5YuG7DysOE/-4_XHR0nwt0J, I'll go ahead and remove wiki:1.1/TracTicketsCustomFields and add the content to TracTicketsCustomFields, if there are no objections. I'm not sure yet whether or not to filter out the 1.1.x material when merging the documentation for 1.0.x.

[Ryan J Ollos]

I've been thinking it would be useful to document somewhere the plugins that are no longer needed due to direct integration or equivalent functionality added to Trac. I noticed we have the special case for WebAdmin plugin documented here: TracUpgrade. I'm not sure whether TracUpgrade is the ideal place to document plugins, and that's primarily what I'm seeking feedback on.

I've made some notes over the past several weeks, and just reviewed ​th:tagged:deprecated as well:

1.1.2:

• ​th:LinenoMacro
• ​th:GroupBasedRedirectionPlugin - Replaced by default handler preference, though this is not a direct replacement since the default handler can't be set for a group. We should be pretty close to equivalent functionality once support is added to ​th:AccountManagerPlugin for setting the default handler through the account management page.

1.1.1:

• ​th:DateFieldPlugin

1.0:

• ​th:BatchModifyPlugin
• ​th:GitPlugin
• ​th:OverrideEditPlugin

0.12.1:

• ​th:RepoRevisionSyntaxPlugin

0.12:

• ​th:AutoQueryPlugin
• ​th:AdminConsoleProviderPatch
• ​th:AnchorMacro
• ​th:TicketChangePlugin
• ​th:TicketDeletePlugin
• ​th:SubversionLocationPlugin
• ​th:WikiCreoleRendererPlugin
• ​th:WikiRenamePlugin

The list would help users know which plugins to uninstall when upgrading (not that I expect many to read the documentation, it still saves time by having documentation to point at from the mailing list). The issue seems to come up on the mailing list from time to time.

[Ryan J Ollos]

In comment:7:ticket:11703 we discussed dropping support for Subversion < 1.6 in Trac 1.2. The change has been documented in wiki:TracDev/ApiChanges/1.1.2#Subversionoptional. The trunk/INSTALL file was updated in [13080].

[Ryan J Ollos]

More changes:

• [13081:13083]: Updated docutils requirement in setup.py to align with wiki:0.12/TracInstall and TracInstall. This was previously mentioned in comment:6:ticket:9915. Trac has required 0.3.9 since [3509]: trunk/trac/mimeview/rst.py@12501:227-229#L219​.
• [13084]: Bumped setuptools requirement on trunk from 0.6b1 to 0.6. This also aligns the enforced requirement with that specified in TracInstall#MandatoryDependencies. ​0.6b1 is from 2006, and while I couldn't find the release date for 0.6, I would be surprised if we need to support such an early version in Trac 1.1.2.
• [13085]: Corrected required version of Babel (follow-on to [13080]).

[Ryan J Ollos]

Replying to rjollos:

As a follow-on to the question posted in ​gmessage:trac-dev:l5YuG7DysOE/-4_XHR0nwt0J, I'll go ahead and remove wiki:1.1/TracTicketsCustomFields and add the content to TracTicketsCustomFields, if there are no objections.

Ah. I had overlooked the statement in TracProject/DefaultWikiPages. I will move the content for the upcoming release to the 1.1/ pages.

[Ryan J Ollos]

TracWorkflow#someideasfornextsteps could be moved to TracIdeas?

It seemed like the right thing to do, so I went ahead and moved it: TracIdeas/TracWorkflow@2#WorkflowActions. Please let me know if there are any comments.

[Ryan J Ollos]

0.12-stable documentation synced in [13089]. 1.0-stable documentation synced in [13094], merged to trunk in [13095].

Changed tag_build to beta1 in [13096:13098]. I think we are ready to create the beta1 packages, but I'll take one more look over the TracDev/ReleaseChecklist tomorrow before doing so.

[Jun Omae]

In [13094], default wiki pages have wrongly the following notices.

$ grep -F 'Note: this page documents' {trunk,branches/*-stable}/trac/wiki/default-pages/*
trunk/trac/wiki/default-pages/TracAdmin:** Note: this page documents the version 1.0 of Trac, see [[0.12/TracAdmin]] if you need the previous version **
branches/1.0-stable/trac/wiki/default-pages/TracAdmin:** Note: this page documents the version 1.0 of Trac, see [[0.12/TracAdmin]] if you need the previous version **

[Ryan J Ollos]

Issue with notice on TracAdmin page fixed in [13099:13100].

[Christian Boos]

So what's the status with setuptools?

According to ​pypa-setuptools-issue:240 we should advise using version ≥ 5.7 or at least setting the PKG_RESOURCES_CACHE_ZIP_MANIFESTS for 5.4-5.6.

Is that correct? If so, we should probably document this or even issue a warning if we autodetect the problematic versions?

[Ryan J Ollos]

Issuing a warning sounds like a good idea. Most users don't read the documentation, and it will be frustrating for users when they upgrade and the performance of Trac becomes very poor. Trac will be blamed even though it is a setuptools issue. I will try to make a patch that causes a warning to be issued.

[Ryan J Ollos]

I added a statement in wiki:setuptools@7?action=diff. Please feel free to improve. It looks like any truthy value would be sufficient for ​PKG_RESOURCES_CACHE_ZIP_MANIFESTS. Is TracInstall the only other page where this should be documented?

[Jun Omae]

+1 for issuing a warning.

Timing of request for /about page:

OS	Egg files	5.3	5.4	5.7
Ubuntu	zipped	214ms	749ms	73ms
Ubuntu	unzipped	31ms	30ms	30ms
Windows	zipped	975ms	3589ms	297ms
Windows	unzipped	75ms	75ms	75ms

• 5.4 with PKG_RESOURCES_CACHE_ZIP_MANIFESTS is the same performance as 5.7.
• Tested on virtualenvs with Python 2.7 installed only Babel, Genshi and Trac 1.0.2beta1-r13099.

[Ryan J Ollos]

Replying to rjollos:

It looks like any truthy value would be sufficient for ​PKG_RESOURCES_CACHE_ZIP_MANIFESTS.

From further testing, even PKG_RESOURCES_CACHE_ZIP_MANIFESTS=0 results in a truthy value since a string is returned. So any value for PKG_RESOURCES_CACHE_ZIP_MANIFESTS should be okay.

$ PKG_RESOURCES_CACHE_ZIP_MANIFESTS=1 python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> bool(os.environ['PKG_RESOURCES_CACHE_ZIP_MANIFESTS'])
True
>>> 
(t11694)user@ubuntu:~/Workspace/t11694$ PKG_RESOURCES_CACHE_ZIP_MANIFESTS= python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> bool(os.environ['PKG_RESOURCES_CACHE_ZIP_MANIFESTS'])
False
>>> 

[Ryan J Ollos]

Initially I tried adding a warning to setup.py, but setup.py install generates so much output that it won't be seen. It probably makes more sense to put the warning in the log anyway. I didn't see a better place to do the logging than the Environment class, but I imagine there might be a better location.

trac/env.py

@@ -220 +220 @@
             for setup_participant in self.setup_participants:
                 setup_participant.environment_created()
 
+        from pkg_resources import parse_version as parse
+        if parse('5.4') <= parse(setuptools.__version__) < parse('5.7') and \
+                not os.environ.get('PKG_RESOURCES_CACHE_ZIP_MANIFESTS'):
+            self.log.warn(
+                "Detected setuptools version %s. The environment variable "
+                "'PKG_RESOURCES_CACHE_ZIP_MANIFESTS' must be set to avoid "
+                "significant performance degradation."
+                % setuptools.__version__)
+
     def get_systeminfo(self):
         """Return a list of `(name, version)` tuples describing the name and
         version information of external packages used by Trac and plugins.

Another possibility might be to print to stdout from trunk/trac/web/standalone.py@12788:299-300,302#L281​.

[Ryan J Ollos]

Before we upgrade t.e.o to 1.1.2, ​th:#11948 will need to be addressed to remove use of the deprecated get_db_cnx from ​th:VotePlugin.

[Ryan J Ollos]

Warnings added to documentation in wiki:TracInstall@376?action=diff&old_version=373. I'm unsure as to whether we need additional steps for the different web servers and web server configurations: TracModWSGI, TracCgi. TracFastCgi, TracOnWindowsIisAjp and TracModPython. I'll do some testing with at least one or two of those.

[Jun Omae]

Replying to rjollos:

Initially I tried adding a warning to setup.py, but setup.py install generates so much output that it won't be seen. It probably makes more sense to put the warning in the log anyway. I didn't see a better place to do the logging than the Environment class, but I imagine there might be a better location.

How about adding to trac.admin.console:run and trac.web.main:dispatch_request? See warn-setuptools-issue.diff​.

Another possibility might be to print to stdout from trunk/trac/web/standalone.py@12788:299-300,302#L281​.

I think we should use environ['wsgi.errors'] rather than if printing to stdout. If mod_wsgi with WSGIRestrictStdout On, it will get IOError: sys.stdout access restricted by mod_wsgi. See ​ConfigurationDirectives#WSGIRestrictStdout and ​DebuggingTechniques.

[Ryan J Ollos]

Sorry for the delay, I had a busy week at work. I'll test out the patches this evening and then resume with the release.

[Ryan J Ollos]

Replying to jomae:

How about adding to trac.admin.console:run and trac.web.main:dispatch_request? See warn-setuptools-issue.diff​.

Looks good, and nice idea to print the message from console admin commands too.

Committed to 0.12-stable in [13115], merged in [13116:13117] (log messages are incorrect about revisions being merged).

[Ryan J Ollos]

Additional documentation changes in wiki:TracInstall@378?action=diff and wiki:0.12/TracInstall@27?action=diff.

[Ryan J Ollos]

Documentation synced in [13118], [13120].

[Ryan J Ollos]

I don't have any VMs with Subversion 1.6 installed so I've been using ​setuptools_subversion. Before installing setuptools_subversion the locale directory was not being included in the distribution, but it looks okay now.

If we find any issues with the package and need to fallback to using Subversion 1.6 I suppose I can build Subversion 1.6 from the source and try to get it installed side-by-side with my Subversion 1.8.x install.

We should probably deal with #10658 before the 0.12.7 / 1.0.3 / 1.1.3 releases.

[Ryan J Ollos]

Should we do builds for both win32 and win-amd64 platforms?

[Jun Omae]

Replying to rjollos:

I don't have any VMs with Subversion 1.6 installed so I've been using ​setuptools_subversion. Before installing setuptools_subversion the locale directory was not being included in the distribution, but it looks okay now.

I cannot reproduce that issue because setuptools_subversion doesn't work on my environment with setuptools 0.6c11 and subversion 1.7.6. Well, that issue is #11640? Also, setuptools 1.4.2 with subversion 1.7 works well.

[Ryan J Ollos]

I was not very clear in my previous comment, and should have mentioned that I was referring to creating the sdist. Anyway, the packages seem to include all of the data files when built with setuptools-subversion installed.

[Christian Boos]

Replying to rjollos:

Should we do builds for both win32 and win-amd64 platforms?

No, win32 is enough (as there's no native code).

Should I build them?

[Jun Omae]

Replying to cboos:

Replying to rjollos:

Should we do builds for both win32 and win-amd64 platforms?

No, win32 is enough (as there's no native code).

Yes. Trac core has no native code. However, trac-admin.exe and tracd.exe would be installed as an executable launcher. Those launchers are native binaries.

[Ryan J Ollos]

Thanks for the feedback. I'll make some additional comments on ​gdiscussion:trac-dev:l5YuG7DysOE soon.

[Christian Boos]

r13123 leads to error: invalid truth value '' when running python setup.py .... Better just comment out the line (# tag_svn_revision = true).

[Ryan J Ollos]

Thanks, I'll fix that now and post the builds to the downloads site.

[Ryan J Ollos]

Error described in comment:33 fixed in [13128:13130].

[Jun Omae]

We should import group3 translations which have no committers from Transifex before releasing. Especially, status of Korean translations is 100%.

[Ryan J Ollos]

Okay. We could revert the revision numbers and checkin the changes, but the revision history will be a little bit ugly either way, so I think we should just go ahead and pull in the changes from Transifex and then I'll delete and recreate the tags before releasing.

[Ryan J Ollos]

I'm going to just release the tags [13152,13154,13156]. I've dragged this on too long already. We should have had an entire release cycle in the time since I planned to do the release (around August 1st). It is my fault for not releasing by now, but we have to live with less having everything less than absolutely perfect. We should aim for a 2 month release cycle and push the next one out with updated translations by Jan 1st.

I'll prepare the packages and upload to the server in the morning, then check with Christian about sending out a release notice email.

[Ryan J Ollos]

The new releases are posted on TracDownload and PyPI. The only step left is to send an announcement email.

[Jun Omae]

Notices have been removed from TracInstall in [13181-13182].

[Ryan J Ollos]

In [13188:13192], added release date and tags to ChangeLogs (as described in TracDev/ReleaseChecklist@42).

[Ryan J Ollos]

Replying to cboos:

According to ​pypa-setuptools-issue:240 we should advise using version ≥ 5.7 or at least setting the PKG_RESOURCES_CACHE_ZIP_MANIFESTS for 5.4-5.6.

Debian 8 (released April 25th) provides setuptools 5.5.1, so we may start seeing the performance issue reported more often now (assuming most users won't read or will ignore the warning we provide).

[Ryan J Ollos]

Replying to rjollos:

I've been thinking it would be useful to document somewhere the plugins that are no longer needed due to direct integration or equivalent functionality added to Trac. I noticed we have the special case for WebAdmin plugin documented here: TracUpgrade. I'm not sure whether TracUpgrade is the ideal place to document plugins, and that's primarily what I'm seeking feedback on.

Documentation added in:

• 1.2: 1.1/TracUpgrade@13 and 1.1/TracUpgrade@14
• 1.0: TracUpgrade@116, merged in 1.1/TracUpgrade@15
• 0.12: TracUpgrade@117, merged in 1.1/TracUpgrade@16