#11694 closed task (fixed)
Release Trac 0.12.6 / 1.0.2 / 1.1.2
Reported by: | Ryan J Ollos | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Milestone: | 1.0.2 |
Component: | general | Version: | |
Severity: | normal | Keywords: | release |
Cc: | Jun Omae | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
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.
Attachments (1)
Change History (46)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Cc: | added |
---|---|
Summary: | Release Trac 0.12..6 / 1.0.2 / 1.1.2 → Release Trac 0.12.6 / 1.0.2 / 1.1.2 |
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/.
follow-up: 8 comment:4 by , 10 years ago
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.
follow-up: 45 comment:5 by , 10 years ago
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:
1.0:
0.12.1:
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.
comment:6 by , 10 years ago
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].
comment:7 by , 10 years ago
More changes:
- [13081:13083]: Updated
docutils
requirement insetup.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]).
comment:8 by , 10 years ago
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.
comment:9 by , 10 years ago
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.
comment:10 by , 10 years ago
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.
comment:11 by , 10 years ago
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 **
follow-up: 44 comment:13 by , 10 years ago
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?
comment:14 by , 10 years ago
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.
follow-up: 17 comment:15 by , 10 years ago
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?
comment:16 by , 10 years ago
+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.
comment:17 by , 10 years ago
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 >>>
follow-up: 21 comment:18 by , 10 years ago
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
diff --git a/trac/env.py b/trac/env.py index 5b9dacf..c36ef84 100644
a b class Environment(Component, ComponentManager): 220 220 for setup_participant in self.setup_participants: 221 221 setup_participant.environment_created() 222 222 223 from pkg_resources import parse_version as parse 224 if parse('5.4') <= parse(setuptools.__version__) < parse('5.7') and \ 225 not os.environ.get('PKG_RESOURCES_CACHE_ZIP_MANIFESTS'): 226 self.log.warn( 227 "Detected setuptools version %s. The environment variable " 228 "'PKG_RESOURCES_CACHE_ZIP_MANIFESTS' must be set to avoid " 229 "significant performance degradation." 230 % setuptools.__version__) 231 223 232 def get_systeminfo(self): 224 233 """Return a list of `(name, version)` tuples describing the name and 225 234 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.
comment:19 by , 10 years ago
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.
comment:20 by , 10 years ago
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.
by , 10 years ago
Attachment: | warn-setuptools-issue.diff added |
---|
follow-up: 23 comment:21 by , 10 years ago
Replying to rjollos:
Initially I tried adding a warning to
setup.py
, butsetup.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 theEnvironment
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.
comment:22 by , 10 years ago
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.
comment:23 by , 10 years ago
Replying to jomae:
How about adding to
trac.admin.console:run
andtrac.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).
comment:24 by , 10 years ago
Additional documentation changes in wiki:TracInstall@378?action=diff and wiki:0.12/TracInstall@27?action=diff.
follow-up: 28 comment:26 by , 10 years ago
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.
follow-up: 30 comment:27 by , 10 years ago
Should we do builds for both win32
and win-amd64
platforms?
comment:28 by , 10 years ago
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
thelocale
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.
comment:29 by , 10 years ago
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.
follow-up: 31 comment:30 by , 10 years ago
Replying to rjollos:
Should we do builds for both
win32
andwin-amd64
platforms?
No, win32 is enough (as there's no native code).
Should I build them?
comment:31 by , 10 years ago
Replying to cboos:
Replying to rjollos:
Should we do builds for both
win32
andwin-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.
comment:32 by , 10 years ago
Thanks for the feedback. I'll make some additional comments on gdiscussion:trac-dev:l5YuG7DysOE soon.
comment:33 by , 10 years ago
r13123 leads to error: invalid truth value ''
when running python setup.py ...
. Better just comment out the line (# tag_svn_revision = true
).
comment:36 by , 10 years ago
We should import group3 translations which have no committers from Transifex before releasing. Especially, status of Korean translations is 100%.
comment:37 by , 10 years ago
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.
comment:38 by , 10 years ago
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.
comment:39 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The new releases are posted on TracDownload and PyPI. The only step left is to send an announcement email.
comment:40 by , 10 years ago
Milestone: | → 1.0.2 |
---|
comment:42 by , 10 years ago
In [13188:13192], added release date and tags to ChangeLog
s (as described in TracDev/ReleaseChecklist@42).
comment:43 by , 10 years ago
Owner: | set to |
---|
comment:44 by , 9 years ago
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).
comment:45 by , 9 years ago
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
[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.