Edgewall Software
Modify

Opened 2 years ago

Closed 12 months ago

Last modified 12 months ago

#12120 closed task (fixed)

Release Trac 1.2

Reported by: Ryan J Ollos Owned by: Ryan J Ollos
Priority: normal Milestone: 1.2
Component: general Version:
Severity: normal Keywords: release
Cc:
Release Notes:
API Changes:

Description (last modified by Ryan J Ollos)

This ticket is used to coordinate the finalization and testing of the next major release of Trac, 1.2.

Documentation tasks:

  • Merge 1.0 documentation changes to 1.1.
  • Add .rst extension to INSTALL and UPGRADE.#12141.

Attachments (1)

20160705T190109.png (21.3 KB ) - added by Jun Omae 17 months ago.

Download all attachments as: .zip

Change History (70)

comment:1 Changed 2 years ago by Ryan J Ollos

Description: modified (diff)

comment:2 Changed 2 years ago by Ryan J Ollos

Description: modified (diff)

comment:3 Changed 2 years ago by Ryan J Ollos

We should keep an eye out for any issues with the Babel 2.0 release that was made today. It doesn't appear there was a large amount of development activity incorporated into the release.

comment:4 Changed 2 years ago by Ryan J Ollos

The Babel development document indicates Python 2.5 is not supported. We should look at whether that's true as of Babel 2.0, and if so, consider enforcing Babel < 2.0 in setup.py for Trac 1.0.9 and later. If Babel 2.0 works with Python 2.5 by chance, we'll at least want to keep an eye on this in future releases.

Last edited 13 months ago by Ryan J Ollos (previous) (diff)

comment:5 Changed 2 years ago by Ryan J Ollos

Description: modified (diff)

Created a separate ticket for releasing Trac 1.0.9 since milestone:1.0.9 and milestone:1.2 will likely not be released at the same time: #12167.

comment:6 Changed 2 years ago by figaro

Type: enhancementtask

comment:7 Changed 2 years ago by Ryan J Ollos

In earlier versions of Trac checkwiki.py was located in wiki-default. It's not in contrib since [4951] so we can remove the entry in tags/trac-1.1.6/trac/wiki/admin.py@:266#L263. Removed in [14367].

comment:8 Changed 2 years ago by Ryan J Ollos

I updated the due date for milestone:1.2 to 31 Jan 2016. I'm hoping we can prepare a beta in early January.

comment:9 Changed 22 months ago by Christian Boos

DONE fix a few minor CSS glitches, mainly related to #11835

  • also, add: trac-author-user { color: #666; }

Another glitch I noticed, on the milestone trac-groupprogress panel, when it's grouped by owner or reporter, when there's a userid → username substitution (#7339), the link to the corresponding query is not present.

Last edited 20 months ago by Ryan J Ollos (previous) (diff)

comment:10 in reply to:  9 Changed 22 months ago by Ryan J Ollos

Replying to Christian Boos:

  • also, add: trac-author-user { color: #666; }

There were some issues documented in #11835 (comment:31:ticket:11835), so I made a new ticket #12347.

Another glitch I noticed, on the milestone trac-groupprogress panel, when it's grouped by owner or reporter, when there's a userid → username substitution (#7339), the link to the corresponding query is not present.

Thanks, I'll fix that issue and comment on the change in #7339.

Last edited 22 months ago by Ryan J Ollos (previous) (diff)

comment:11 Changed 22 months ago by Ryan J Ollos

On tidying up the svn:mergeinfo I noticed that [14500] and [14501] haven't been merged to trunk yet. I just wanted to make note of that in case it's an oversight.

comment:12 Changed 21 months ago by Ryan J Ollos

I'm considering preparing a release candidate the weekend of March 26th-27th. Please chime in if you have any thoughts on that schedule.

Most of the tickets in milestone:1.2 are assigned to me. If anyone wants to pickup any tickets, please feel to grab them, particularly #11837, #11928 and #12209. The only tickets I'm actively working on at the moment are #12257 and #12299.

comment:13 in reply to:  12 ; Changed 20 months ago by Ryan J Ollos

Replying to Ryan J Ollos:

I'm considering preparing a release candidate the weekend of March 26th-27th. Please chime in if you have any thoughts on that schedule.

Most of the tickets in milestone:1.2 are assigned to me. If anyone wants to pickup any tickets, please feel to grab them, particularly #11837, #11928 and #12209. The only tickets I'm actively working on at the moment are #12257 and #12299.

I'm still aiming to complete #12257 and #12299, and will move the other tickets forward if there is not enough time. My goal is still to get the release candidate out by the end of next weekend.

comment:14 in reply to:  13 ; Changed 20 months ago by Ryan J Ollos

Replying to Ryan J Ollos:

I'm still aiming to complete #12257 and #12299, and will move the other tickets forward if there is not enough time. My goal is still to get the release candidate out by the end of next weekend.

I've been rather busy and unable to complete these steps so far. I'll aim to prepare a release candidate by the end of the coming weekend, but even if this slips further I will at least have it prepared by April 10th.

comment:15 Changed 20 months ago by Ryan J Ollos

[10842] removed the test case that utilized MockMySQLConnection. Removed MockMySQLConnection in [14658].

comment:16 Changed 20 months ago by Ryan J Ollos

Removed unused imports in [14661,14665]. PEP8 changes in [14662].

Last edited 20 months ago by Ryan J Ollos (previous) (diff)

comment:17 Changed 20 months ago by Ryan J Ollos

It looks like there might be an unnecessary cursor.close() from when the pre-Trac-1.0 DB API was used. Is there any reason to have that? Also, it appears some code could be moved outside the transaction block.

  • trac/ticket/query.py

    diff --git a/trac/ticket/query.py b/trac/ticket/query.py
    index 5f4db18..5f0fc10 100644
    a b class Query(object):  
    289289        """
    290290        if req is not None:
    291291            href = req.href
    292         with self.env.db_query as db:
    293             cursor = db.cursor()
    294 
    295             self.num_items = 0
    296             sql, args = self.get_sql(req, cached_ids, authname, tzinfo, locale)
    297             self.num_items = self._count(sql, args)
    298292
    299             if self.num_items <= self.max:
    300                 self.has_more_pages = False
     293        self.num_items = 0
     294        sql, args = self.get_sql(req, cached_ids, authname, tzinfo, locale)
     295        self.num_items = self._count(sql, args)
    301296
    302             if self.has_more_pages:
    303                 max = self.max
    304                 if self.group:
    305                     max += 1
    306                 sql += " LIMIT %d OFFSET %d" % (max, self.offset)
    307                 if (self.page > int(ceil(float(self.num_items) / self.max)) and
    308                         self.num_items != 0):
    309                     raise TracError(_("Page %(page)s is beyond the number of "
    310                                       "pages in the query", page=self.page))
     297        if self.num_items <= self.max:
     298            self.has_more_pages = False
    311299
     300        if self.has_more_pages:
     301            max = self.max
     302            if self.group:
     303                max += 1
     304            sql += " LIMIT %d OFFSET %d" % (max, self.offset)
     305            if (self.page > int(ceil(float(self.num_items) / self.max)) and
     306                self.num_items != 0):
     307                raise TracError(_("Page %(page)s is beyond the number of "
     308                                  "pages in the query", page=self.page))
     309
     310        results = []
     311        with self.env.db_query as db:
     312            cursor = db.cursor()
    312313            cursor.execute(sql, args)
    313314            columns = get_column_names(cursor)
    314315            fields = [self.fields.by_name(column, None) for column in columns]
    315             results = []
    316316
    317317            column_indices = range(len(columns))
    318318            for row in cursor:
    class Query(object):  
    333333                        val = ''
    334334                    result[name] = val
    335335                results.append(result)
    336             cursor.close()
    337336            return results
    338337
    339338    def get_href(self, href, id=None, order=None, desc=None, format=None,
Last edited 20 months ago by Ryan J Ollos (previous) (diff)

comment:18 Changed 20 months ago by Ryan J Ollos

comment:17 changes committed to trunk in [14680].

comment:19 Changed 20 months ago by Ryan J Ollos

Refactoring in [14689]. CI test failed, but unrelated to changes: #12445.

comment:20 Changed 20 months ago by Ryan J Ollos

Additional refactoring in [14690:14691].

comment:21 Changed 20 months ago by Ryan J Ollos

Proposed change to add a link to SQLite extensions documentation.

  • trac/db/sqlite_backend.py

    diff --git a/trac/db/sqlite_backend.py b/trac/db/sqlite_backend.py
    index f72a9d7..df8e289 100644
    a b class SQLiteConnector(Component):  
    153153    required = False
    154154
    155155    extensions = ListOption('sqlite', 'extensions',
    156         doc="""Paths to sqlite extensions, relative to Trac environment's
    157         directory or absolute. (''since 0.12'')""")
     156        doc="""Paths to [https://sqlite.org/loadext.html sqlite extensions].
     157        The paths may be absolute or relative to Trac environment.
     158        (''since 0.12'')
     159        """)
    158160
    159161    memory_cnx = None
    160162

comment:22 Changed 20 months ago by Ryan J Ollos

comment:21 change committed to trunk in [14715].

comment:23 Changed 20 months ago by Ryan J Ollos

We could change the two places in Option documentation that reference the SVN book to point to the latest stable version of the SVN book. It looks like they are behind on updating the book since 1.9 is the latest stable release.

  • trac/versioncontrol/svn_authz.py

     
    123123
    124124    authz_file = PathOption('svn', 'authz_file', '',
    125125        """The path to the Subversion
    126         [http://svnbook.red-bean.com/en/1.6/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
     126        [http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
    127127        To enable authz permission checking, the `AuthzSourcePolicy` permission
    128128        policy must be added to `[trac] permission_policies`. Non-absolute
    129129        paths are relative to the Environment `conf` directory.
  • tracopt/versioncontrol/svn/svn_prop.py

     
    5959        be mapped to `http://ourserver/tracs/tools/browser/tags/1.1/tools?rev=`
    6060        (and `rev` will be set to the appropriate revision number if the
    6161        external additionally specifies a revision, see the
    62         [http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html SVN Book on externals]
     62        [http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html SVN Book on externals]
    6363        for more details).
    6464
    6565        Note that the number used as a key in the above section is purely used

comment:24 Changed 20 months ago by Ryan J Ollos

comment:23 committed to trunk in [14726].

comment:25 in reply to:  14 Changed 19 months ago by Ryan J Ollos

Replying to Ryan J Ollos:

I've been rather busy and unable to complete these steps so far. I'll aim to prepare a release candidate by the end of the coming weekend, but even if this slips further I will at least have it prepared by April 10th.

I'm not even meeting my worst case estimates. Changes have been proposed for #12257, and I'll give them another review in a few days. I've been working on #12299 and should have proposed changes posted this week. After that, on to preparing the release candidate.

comment:26 in reply to:  24 ; Changed 19 months ago by Jun Omae

Replying to Ryan J Ollos:

comment:23 committed to trunk in [14726].

We could extract that URLs in option documentation via doc_args for trunk.

  • trac/versioncontrol/svn_authz.py

    diff --git a/trac/versioncontrol/svn_authz.py b/trac/versioncontrol/svn_authz.py
    index 787418d5b..8867533b7 100644
    a b class AuthzSourcePolicy(Component):  
    123123
    124124    authz_file = PathOption('svn', 'authz_file', '',
    125125        """The path to the Subversion
    126         [http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
     126        [%(svnbook)s authorization (authz) file].
    127127        To enable authz permission checking, the `AuthzSourcePolicy` permission
    128128        policy must be added to `[trac] permission_policies`. Non-absolute
    129129        paths are relative to the Environment `conf` directory.
    130         """)
     130        """,
     131        doc_args={'svnbook': 'http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html'})
    131132
    132133    authz_module_name = Option('svn', 'authz_module_name', '',
    133134        """The module prefix used in the `authz_file` for the default
  • tracopt/versioncontrol/svn/svn_prop.py

    diff --git a/tracopt/versioncontrol/svn/svn_prop.py b/tracopt/versioncontrol/svn/svn_prop.py
    index 7d9e7a224..19abe3953 100644
    a b class SubversionPropertyRenderer(Component):  
    5959        be mapped to `http://ourserver/tracs/tools/browser/tags/1.1/tools?rev=`
    6060        (and `rev` will be set to the appropriate revision number if the
    6161        external additionally specifies a revision, see the
    62         [http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html SVN Book on externals]
    63         for more details).
     62        [%(svnbook)s SVN Book on externals] for more details).
    6463
    6564        Note that the number used as a key in the above section is purely used
    6665        as a place holder, as the URLs themselves can't be used as a key due to
    class SubversionPropertyRenderer(Component):  
    6968        Finally, the relative URLs introduced in
    7069        [http://subversion.apache.org/docs/release-notes/1.5.html#externals Subversion 1.5]
    7170        are not yet supported.
    72         """)
     71        """,
     72        doc_args={'svnbook': 'http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html'})
    7373
    7474    def __init__(self):
    7575        self._externals_map = {}

comment:27 in reply to:  26 Changed 19 months ago by Christian Boos

Replying to Jun Omae:

Replying to Ryan J Ollos:

comment:23 committed to trunk in [14726].

We could extract that URLs in option documentation via doc_args for trunk.

Or, even simpler and more robust, we could lmgtfy the help text:

  • Search for "Subversion Path-Based Authorization" for more details
  • Search for "Subversion Externals Definitions" for more details

comment:28 Changed 19 months ago by Ryan J Ollos

Searching is probably fine, but it's kind of nice to have a link that points to the section of the very fine svn book. If we retain the latter, pulling the links out as arguments seems like a good improvement (comment:26).

comment:29 Changed 19 months ago by Ryan J Ollos

t.e.o is now running r14757.

comment:30 Changed 19 months ago by Ryan J Ollos

TODO Create a /demo-1.2.

DONE Create branches on Transifex for 1.2-stable (or will be created automatically?).

Last edited 13 months ago by Ryan J Ollos (previous) (diff)

comment:31 Changed 19 months ago by anonymous

comment:26 changes committed in [14768].

comment:32 Changed 17 months ago by anonymous

Hi there! When the 1.2 will be available? I'm couple of weeks between wait for it or install 1.0 on the other hand. Many thanks.

comment:33 Changed 17 months ago by Ryan J Ollos

1.2 should be released in July, and we should have a release candidate ready by next weekend. However, you should be fine to start with 1.0.11 and then upgrade to 1.2 when it's released.

comment:34 Changed 17 months ago by Ryan J Ollos

Owner: set to Ryan J Ollos
Status: newassigned

comment:35 Changed 17 months ago by Ryan J Ollos

I created branches/1.2-stable from trunk in r14877. In r14878, bumped trunk to 1.3.1 and in r14879 set minimum Python version to 2.7. The Appveyor configuration still needs to be modified.

comment:36 Changed 17 months ago by Ryan J Ollos

branches/1.2-stable hasn't been mirrored up to GitHub. Is an explicit action needed to make that happen?

comment:37 in reply to:  36 Changed 17 months ago by Christian Boos

Replying to Ryan J Ollos:

branches/1.2-stable hasn't been mirrored up to GitHub. Is an explicit action needed to make that happen?

Should be fixed (by editing /var/git/trac/mirror/config)

comment:38 Changed 17 months ago by Ryan J Ollos

I see 1.2-stable at both mirror@1.2-stable and GitHub now. Thanks!

comment:39 Changed 17 months ago by Jun Omae

We should revise branches/1.2-stable/.tx/config for new 1.2-stable branch.

  • branches/1.2-stable/.tx/config

     
    11[main]
    22host = https://www.transifex.com
    33
    4 [trac.trunk-messages-js-pot]
     4[trac.1_2-stable-messages-js-pot]
    55file_filter = trac/locale/<lang>/LC_MESSAGES/messages-js.po
    66source_file = trac/locale/messages-js.pot
    77source_lang = en
    88
    9 [trac.trunk-messages-pot]
     9[trac.1_2-stable-messages-pot]
    1010file_filter = trac/locale/<lang>/LC_MESSAGES/messages.po
    1111source_file = trac/locale/messages.pot
    1212source_lang = en
    1313
    14 [trac.trunk-tracini-pot]
     14[trac.1_2-stable-tracini-pot]
    1515file_filter = trac/locale/<lang>/LC_MESSAGES/tracini.po
    1616source_file = trac/locale/tracini.pot
    1717source_lang = en

However, my commit is refused. Could anyone please commit it?

Sending        .tx/config
Transmitting file data .svn: E195023: Commit failed (details follow):
svn: E195023: Changing file '/home/jun66j5/src/tracdev/svn/branches/1.2-stable/.tx/config' is forbidden by the server
svn: E175013: Access to '/repos/trac/!svn/txr/14954-boq/branches/1.2-stable/.tx/config' forbidden
svn: E175002: Additional errors:
svn: E175002: PUT of '/repos/trac/!svn/txr/14954-boq/branches/1.2-stable/.tx/config': 403 Forbidden
svn: E195023: Your commit message was left in a temporary file:
svn: E195023:    '/home/jun66j5/src/tracdev/svn/branches/svn-commit.tmp'
Last edited 17 months ago by Jun Omae (previous) (diff)

Changed 17 months ago by Jun Omae

Attachment: 20160705T190109.png added

comment:40 Changed 17 months ago by Jun Omae

It seems resource 1.2-stable - trac/locale/messages-js.pot incorrectly refers messages.po.

Transifex says that resource has 1,424 strings but messages-js.pot file has 54 strings. Currently, messages-js.po for Japanese cannot be updated (I cannot try to fix it cause of no admin privileges on Transifex).

$ pwd
/home/jun66j5/src/tracdev/svn/branches/1.2-stable
$ make stats-pot
translation statistics for catalog templates:
trac/locale/messages.pot: 0 translated messages, 1424 untranslated messages.
trac/locale/messages-js.pot: 0 translated messages, 54 untranslated messages.
trac/locale/tracini.pot: 0 translated messages, 192 untranslated messages.

comment:41 in reply to:  35 Changed 17 months ago by Christian Boos

Replying to Ryan J Ollos:

… The Appveyor configuration still needs to be modified.

Done in r14945.

comment:42 Changed 17 months ago by Ryan J Ollos

comment:39 change committed in r14956.

I don't immediately see why the commit would have failed, but DONE /var/www/edgewall.org/trac_authz needs to have rules added for 1.2-stable.

I fixed the messages-js.pot file on Transifex just now. Thanks for spotting.

Last edited 12 months ago by Ryan J Ollos (previous) (diff)

comment:43 Changed 17 months ago by Jun Omae

tx status command failed with [14956].

$ tx status
trac -> 1_2-stable-messages-js-pot (1 of 3)
Translation Files:
 - en: trac/locale/messages-js.pot (source)
 ...
 - zh_TW: trac/locale/zh_TW/LC_MESSAGES/messages-js.po

ValueError: too many values to unpack

Please apply the following:

-[trac..1_2-stable-messages-pot]
+[trac.1_2-stable-messages-pot]

comment:44 Changed 17 months ago by Ryan J Ollos

Sorry about that. Regression fixed in r14957.

comment:45 Changed 16 months ago by Ryan J Ollos

With the additions in r12710 and r14984, is the get_column_names function still useful?

comment:46 Changed 16 months ago by Ryan J Ollos

I will fix test failure due to r14984. Test doesn't fail for me with PostgreSQL 9.5.3, however Travis is probably running an earlier version.

A simple fix for the test would be to sort the lists, or write the test like in [12710#file3]. However, it seems odd that some version of PostgreSQL doesn't return the columns in the order they are defined in the schema. Maybe there is a fix that could be implemented in the backend.

Last edited 16 months ago by Ryan J Ollos (previous) (diff)

comment:47 in reply to:  45 Changed 16 months ago by Jun Omae

Replying to Ryan J Ollos:

With the additions in r12710 and r14984, is the get_column_names function still useful?

The 2 functions are not same. The trac.db.api.get_column_names returns list of each field's name from sql query. ReportModule uses it to retrieve field names from user-defined sql. We shouldn't delete it.

comment:48 in reply to:  46 ; Changed 16 months ago by Jun Omae

Replying to Ryan J Ollos:

I will fix test failure due to r14984.

Adding ORDER BY ordinal_position to mysql and postgresql would fix it.

The get_column_names is added to each database backend in r12710. However, missing unit tests for it. We should add unit tests to 1.0-stable as well as r14984.

comment:49 Changed 16 months ago by Ryan J Ollos

r14986 didn't work to echo PostgreSQL version, so maybe it would be better to add the echo to the Makefile.

comment:50 in reply to:  48 ; Changed 16 months ago by Ryan J Ollos

Replying to Jun Omae:

The get_column_names is added to each database backend in r12710. However, missing unit tests for it. We should add unit tests to 1.0-stable as well as r14984.

There is a test for it: [12710#file3]. However, I will rework the test so that the ordering is also tested.

comment:51 in reply to:  50 Changed 16 months ago by Jun Omae

Replying to Ryan J Ollos:

Replying to Jun Omae:

The get_column_names is added to each database backend in r12710. However, missing unit tests for it. We should add unit tests to 1.0-stable as well as r14984.

There is a test for it: [12710#file3]. However, I will rework the test so that the ordering is also tested.

Ah, sorry. I overlooked it.

comment:52 in reply to:  49 ; Changed 16 months ago by Ryan J Ollos

Replying to Ryan J Ollos:

r14986 didn't work to echo PostgreSQL version, so maybe it would be better to add the echo to the Makefile.

How about this change?

  • Makefile

    diff --git a/Makefile b/Makefile
    index b0d7c85..775735f 100644
    a b status:  
    159159       @git --version 2>/dev/null || echo "not installed"
    160160       @echo -n "  Subversion version: "
    161161       @svn --version -q 2>/dev/null || echo "not installed"
     162       @echo -n "  PostreSQL version: "
     163       @psql --version 2>/dev/null || echo "not installed"
     164       @echo -n "  MySQL version: "
     165       @mysql --version 2>/dev/null || echo "not installed"
    162166       @echo
    163167
    164168Trac.egg-info: status

One other thing, on OSX at least the -n argument of echo is printed:

External dependencies:
-n   Git version: 
git version 2.9.2
-n   Subversion version: 
1.9.4
-n   PostreSQL version: 
psql (PostgreSQL) 9.5.3
-n   MySQL version: 
mysql  Ver 14.14 Distrib 5.7.13, for osx10.11 (x86_64) using  EditLine wrapper

The man page for echo notes:

Some shells may provide a builtin echo command which is similar or iden-
tical to this utility.  Most notably, the builtin echo in sh(1) does not
accept the -n option.  Consult the builtin(1) manual page.

comment:53 in reply to:  49 ; Changed 16 months ago by Jun Omae

Replying to Ryan J Ollos:

r14986 didn't work to echo PostgreSQL version, so maybe it would be better to add the echo to the Makefile.

[14986,14987] are good idea however I think we might be better to show server's version rather than client's version.

$ mysql -u root -e 'SELECT version()'
+-------------------------+
| version()               |
+-------------------------+
| 5.5.49-0ubuntu0.14.04.1 |
+-------------------------+
$ psql -U postgres -c 'SELECT version()'
                                                   version
-------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1.20 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
(1 row)

(Updated) retrieving only server's version via command-line:

$ echo "$(psql -U postgres -t -c 'SELECT version()')"
 PostgreSQL 9.1.20 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
$ echo "$(mysql -u root -sN -e 'SELECT version()')"
5.5.49-0ubuntu0.14.04.1
Last edited 16 months ago by Jun Omae (previous) (diff)

comment:54 in reply to:  52 ; Changed 16 months ago by Jun Omae

Replying to Ryan J Ollos:

One other thing, on OSX at least the -n argument of echo is printed:

I think we could use printf builtin command instead of echo -n. See https://github.com/jun66j5/trac/commit/7a988b17a03977173edfb04138495de7cbe6b01e.

comment:55 in reply to:  54 Changed 16 months ago by Ryan J Ollos

Replying to Jun Omae:

I think we could use printf builtin command instead of echo -n. See https://github.com/jun66j5/trac/commit/7a988b17a03977173edfb04138495de7cbe6b01e.

That works well, thanks. Committed to 1.0-stable in r14988, merged in r14989, r14990.

I'll prepare additional changes soon.

comment:56 in reply to:  48 Changed 16 months ago by Ryan J Ollos

Replying to Jun Omae:

Replying to Ryan J Ollos:

I will fix test failure due to r14984.

Adding ORDER BY ordinal_position to mysql and postgresql would fix it.

I applied your fix in r14991, merged to trunk in r14992.

comment:57 in reply to:  53 Changed 16 months ago by Ryan J Ollos

Replying to Jun Omae:

(Updated) retrieving only server's version via command-line:

$ echo "$(psql -U postgres -t -c 'SELECT version()')"
 PostgreSQL 9.1.20 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
$ echo "$(mysql -u root -sN -e 'SELECT version()')"
5.5.49-0ubuntu0.14.04.1

Committed to 1.0-stable in r14993:r14994, however I'd like to suppress the:

The command "echo "$(psql -U postgres -t -c 'SELECT version()')"" exited with 0.

and

The command "echo "$(mysql -u root -sN -e 'SELECT version()')"" exited with 0.

Experimenting in my repository

comment:58 Changed 16 months ago by Ryan J Ollos

r14993:r14994 merged to 1.2-stable in r15004, merged to trunk in r15005.

comment:59 Changed 16 months ago by Ryan J Ollos

I'm fixing #12561 and will create the release candidate on Sunday, 08/21. Please commit any changes you want in 1.2 before then, or else let me know and I'll delay creating the release candidate.

comment:60 Changed 13 months ago by anonymous

succeeded with the release candidate?

comment:61 Changed 13 months ago by anonymous

will you please update the schedule? we are trying to plan our infrastructure upgrade and basically the only thing we are waiting for is the new trac

comment:62 Changed 13 months ago by Ryan J Ollos

#12615 needs to be resolved. Release should happen this week, but I've been pretty busy with work.

comment:63 Changed 13 months ago by Ryan J Ollos

Release has been published. I missed a step that was corrected in r15205.

TracDev/ReleaseNotes and TracDev/ApiChanges need updates (e.g. release announcement pointed to TracDev/ReleaseNotes/1.1 since that page needs to be finalized and then copied to TracDev/ReleaseNotes/1.2). Some work also needs to be done on wiki pages (TracProject/DefaultWikiPages#Migratingtoanewmajorrelease). I'll leave this ticket open until I complete those items.

comment:64 Changed 13 months ago by Ryan J Ollos

Description: modified (diff)

comment:65 in reply to:  63 ; Changed 12 months ago by Christian Boos

Replying to Ryan J Ollos:

Release has been published. I missed a step that was corrected in r15205.

TracDev/ReleaseNotes and TracDev/ApiChanges need updates (e.g. release announcement pointed to TracDev/ReleaseNotes/1.1 since that page needs to be finalized and then copied to TracDev/ReleaseNotes/1.2). Some work also needs to be done on wiki pages (TracProject/DefaultWikiPages#Migratingtoanewmajorrelease). I'll leave this ticket open until I complete those items.

These should be OK now, I think you can close the ticket Ryan, unless I've missed something.

One last thing I did in TracDev/ReleaseNotes/1.2 is to include all the 1.1.x releases in the feature overview, so that one has the overview of all features added since 1.0.

comment:66 Changed 12 months ago by Ryan J Ollos

Resolution: fixed
Status: assignedclosed

comment:67 in reply to:  65 ; Changed 12 months ago by Ryan J Ollos

Replying to Christian Boos:

One last thing I did in TracDev/ReleaseNotes/1.2 is to include all the 1.1.x releases in the feature overview, so that one has the overview of all features added since 1.0.

That looks good, I was considering making that change as well.

Some changelog entries on the Release Notes page are empty because the ticket was a task, or contained only API Changes. I was thinking we should filter those out. By experimenting I found that adding changelog~= to the ticket query filters out empty entries. Does that make sense, or am I exploiting some undefined or buggy behavior?

comment:68 in reply to:  67 Changed 12 months ago by Ryan J Ollos

Replying to Ryan J Ollos:

Replying to Christian Boos:

One last thing I did in TracDev/ReleaseNotes/1.2 is to include all the 1.1.x releases in the feature overview, so that one has the overview of all features added since 1.0.

That looks good, I was considering making that change as well.

Some changelog entries on the Release Notes page are empty because the ticket was a task, or contained only API Changes. I was thinking we should filter those out. By experimenting I found that adding changelog~= to the ticket query filters out empty entries. Does that make sense, or am I exploiting some undefined or buggy behavior?

After looking at the TicketQuery in TracDev/ApiChanges/1.1 (which contains parameter apichanges!=), and looking more closely at the TicketQuery in TracDev/ReleaseNotes/1.2, I see why changelog!= was not working. There's a parameter changelog!=API only|-. So we should put - or API only in the Release Notes field for the case of API only changes?

Last edited 12 months ago by Ryan J Ollos (previous) (diff)

comment:69 Changed 12 months ago by Ryan J Ollos

Edited TracDev/ReleaseNotes/1.2@4. The use of API only and/or - would be more intentional and reduce the risk that we forget to add an entry for Release Notes, however the Release Notes for the milestone are reviewed when preparing a release, so I think we have a process that will catch unintentionally empty Release Notes entries.

Modify Ticket

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