Edgewall Software
Modify

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

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

warn-setuptools-issue.diff (3.1 KB ) - added by Jun Omae 6 years ago.

Download all attachments as: .zip

Change History (46)

comment:1 by Ryan J Ollos, 6 years ago

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

comment:2 by Jun Omae, 6 years ago

Cc: Jun Omae added
Summary: Release Trac 0.12..6 / 1.0.2 / 1.1.2Release 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/.

comment:3 by anonymous, 6 years ago

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

comment:4 by Ryan J Ollos, 6 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.

comment:5 by Ryan J Ollos, 6 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:

1.1.1:

1.0:

0.12.1:

0.12:

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 Ryan J Ollos, 6 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].

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

comment:7 by Ryan J Ollos, 6 years ago

More changes:

in reply to:  4 comment:8 by Ryan J Ollos, 6 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 Ryan J Ollos, 6 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 Ryan J Ollos, 6 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 Jun Omae, 6 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 **

comment:12 by Ryan J Ollos, 6 years ago

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

comment:13 by Christian Boos, 6 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 Ryan J Ollos, 6 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.

comment:15 by Ryan J Ollos, 6 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 Jun Omae, 6 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.

in reply to:  15 comment:17 by Ryan J Ollos, 6 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
>>> 

comment:18 by Ryan J Ollos, 6 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):  
    220220            for setup_participant in self.setup_participants:
    221221                setup_participant.environment_created()
    222222
     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
    223232    def get_systeminfo(self):
    224233        """Return a list of `(name, version)` tuples describing the name and
    225234        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 Ryan J Ollos, 6 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 Ryan J Ollos, 6 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.

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

by Jun Omae, 6 years ago

Attachment: warn-setuptools-issue.diff added

in reply to:  18 ; comment:21 by Jun Omae, 6 years ago

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.

Last edited 6 years ago by Jun Omae (previous) (diff)

comment:22 by Ryan J Ollos, 6 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.

in reply to:  21 comment:23 by Ryan J Ollos, 6 years ago

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

comment:24 by Ryan J Ollos, 6 years ago

comment:25 by Ryan J Ollos, 6 years ago

Documentation synced in [13118], [13120].

comment:26 by Ryan J Ollos, 6 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.

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

comment:27 by Ryan J Ollos, 6 years ago

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

in reply to:  26 comment:28 by Jun Omae, 6 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 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.

Last edited 6 years ago by Jun Omae (previous) (diff)

comment:29 by Ryan J Ollos, 6 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.

in reply to:  27 ; comment:30 by Christian Boos, 6 years ago

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?

in reply to:  30 comment:31 by Jun Omae, 6 years ago

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.

comment:32 by Ryan J Ollos, 6 years ago

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

comment:33 by Christian Boos, 6 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:34 by Ryan J Ollos, 6 years ago

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

comment:35 by Ryan J Ollos, 6 years ago

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

comment:36 by Jun Omae, 6 years ago

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

Last edited 6 years ago by Jun Omae (previous) (diff)

comment:37 by Ryan J Ollos, 6 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 Ryan J Ollos, 6 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 Ryan J Ollos, 6 years ago

Resolution: fixed
Status: newclosed

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

comment:40 by Ryan J Ollos, 6 years ago

Milestone: 1.0.2

comment:41 by Jun Omae, 6 years ago

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

comment:42 by Ryan J Ollos, 6 years ago

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

comment:43 by Ryan J Ollos, 6 years ago

Owner: set to Ryan J Ollos

in reply to:  13 comment:44 by Ryan J Ollos, 6 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).

in reply to:  5 comment:45 by Ryan J Ollos, 5 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:

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Ryan J Ollos 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.