Release Trac 1.2

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

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

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

[Ryan J Ollos]

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.

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

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

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

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

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

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

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

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

[Ryan J Ollos]

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

[Ryan J Ollos]

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

[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

@@ -289 +289 @@
         """
         if req is not None:
             href = req.href
-        with self.env.db_query as db:
-            cursor = db.cursor()
-
-            self.num_items = 0
-            sql, args = self.get_sql(req, cached_ids, authname, tzinfo, locale)
-            self.num_items = self._count(sql, args)
 
-            if self.num_items <= self.max:
-                self.has_more_pages = False
+        self.num_items = 0
+        sql, args = self.get_sql(req, cached_ids, authname, tzinfo, locale)
+        self.num_items = self._count(sql, args)
 
-            if self.has_more_pages:
-                max = self.max
-                if self.group:
-                    max += 1
-                sql += " LIMIT %d OFFSET %d" % (max, self.offset)
-                if (self.page > int(ceil(float(self.num_items) / self.max)) and
-                        self.num_items != 0):
-                    raise TracError(_("Page %(page)s is beyond the number of "
-                                      "pages in the query", page=self.page))
+        if self.num_items <= self.max:
+            self.has_more_pages = False
 
+        if self.has_more_pages:
+            max = self.max
+            if self.group:
+                max += 1
+            sql += " LIMIT %d OFFSET %d" % (max, self.offset)
+            if (self.page > int(ceil(float(self.num_items) / self.max)) and
+                self.num_items != 0):
+                raise TracError(_("Page %(page)s is beyond the number of "
+                                  "pages in the query", page=self.page))
+
+        results = []
+        with self.env.db_query as db:
+            cursor = db.cursor()
             cursor.execute(sql, args)
             columns = get_column_names(cursor)
             fields = [self.fields.by_name(column, None) for column in columns]
-            results = []
 
             column_indices = range(len(columns))
             for row in cursor:
@@ -333 +333 @@
                         val = ''
                     result[name] = val
                 results.append(result)
-            cursor.close()
             return results
 
     def get_href(self, href, id=None, order=None, desc=None, format=None,

[Ryan J Ollos]

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

[Ryan J Ollos]

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

[Ryan J Ollos]

Additional refactoring in [14690:14691].

[Ryan J Ollos]

Proposed change to add a link to SQLite extensions documentation.

trac/db/sqlite_backend.py

@@ -153 +153 @@
     required = False
 
     extensions = ListOption('sqlite', 'extensions',
-        doc="""Paths to sqlite extensions, relative to Trac environment's
-        directory or absolute. (''since 0.12'')""")
+        doc="""Paths to [https://sqlite.org/loadext.html sqlite extensions].
+        The paths may be absolute or relative to Trac environment.
+        (''since 0.12'')
+        """)
 
     memory_cnx = None
 

[Ryan J Ollos]

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

[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

@@ -123 +123 @@
 
     authz_file = PathOption('svn', 'authz_file', '',
         """The path to the Subversion
-        [http://svnbook.red-bean.com/en/1.6/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
+        [http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
         To enable authz permission checking, the `AuthzSourcePolicy` permission
         policy must be added to `[trac] permission_policies`. Non-absolute
         paths are relative to the Environment `conf` directory.

tracopt/versioncontrol/svn/svn_prop.py

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

[Ryan J Ollos]

comment:23 committed to trunk in [14726].

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

[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

@@ -123 +123 @@
 
     authz_file = PathOption('svn', 'authz_file', '',
         """The path to the Subversion
-        [http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html authorization (authz) file].
+        [%(svnbook)s authorization (authz) file].
         To enable authz permission checking, the `AuthzSourcePolicy` permission
         policy must be added to `[trac] permission_policies`. Non-absolute
         paths are relative to the Environment `conf` directory.
-        """)
+        """,
+        doc_args={'svnbook': 'http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html'})
 
     authz_module_name = Option('svn', 'authz_module_name', '',
         """The module prefix used in the `authz_file` for the default

tracopt/versioncontrol/svn/svn_prop.py

@@ -59 +59 @@
         be mapped to `http://ourserver/tracs/tools/browser/tags/1.1/tools?rev=`
         (and `rev` will be set to the appropriate revision number if the
         external additionally specifies a revision, see the
-        [http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html SVN Book on externals]
-        for more details).
+        [%(svnbook)s SVN Book on externals] for more details).
 
         Note that the number used as a key in the above section is purely used
         as a place holder, as the URLs themselves can't be used as a key due to
@@ -69 +68 @@
         Finally, the relative URLs introduced in
         [http://subversion.apache.org/docs/release-notes/1.5.html#externals Subversion 1.5]
         are not yet supported.
-        """)
+        """,
+        doc_args={'svnbook': 'http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html'})
 
     def __init__(self):
         self._externals_map = {}

[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

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

[Ryan J Ollos]

t.e.o is now running r14757.

[Ryan J Ollos]

TODO Create a /demo-1.2.

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

[anonymous]

comment:26 changes committed in [14768].

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

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

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

[Ryan J Ollos]

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

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

[Ryan J Ollos]

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

[Jun Omae]

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

branches/1.2-stable/.tx/config

@@ -1 +1 @@
 [main]
 host = https://www.transifex.com
 
-[trac.trunk-messages-js-pot]
+[trac.1_2-stable-messages-js-pot]
 file_filter = trac/locale/<lang>/LC_MESSAGES/messages-js.po
 source_file = trac/locale/messages-js.pot
 source_lang = en
 
-[trac.trunk-messages-pot]
+[trac.1_2-stable-messages-pot]
 file_filter = trac/locale/<lang>/LC_MESSAGES/messages.po
 source_file = trac/locale/messages.pot
 source_lang = en
 
-[trac.trunk-tracini-pot]
+[trac.1_2-stable-tracini-pot]
 file_filter = trac/locale/<lang>/LC_MESSAGES/tracini.po
 source_file = trac/locale/tracini.pot
 source_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'

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

[Christian Boos]

Replying to Ryan J Ollos:

… The Appveyor configuration still needs to be modified.

Done in r14945.

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

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

[Ryan J Ollos]

Sorry about that. Regression fixed in r14957.

[Ryan J Ollos]

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

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

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

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

• PostgreSQL:
  • ​https://www.postgresql.org/docs/8.0/static/infoschema-columns.html
  • ​https://www.postgresql.org/docs/9.5/static/infoschema-columns.html
• MySQL:
  • ​https://docs.oracle.com/cd/E19078-01/mysql/mysql-refman-5.0/information-schema.html#columns-table
  • ​http://dev.mysql.com/doc/refman/5.7/en/columns-table.html

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.

[Ryan J Ollos]

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

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

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

[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

@@ -159 +159 @@
        @git --version 2>/dev/null || echo "not installed"
        @echo -n "  Subversion version: "
        @svn --version -q 2>/dev/null || echo "not installed"
+       @echo -n "  PostreSQL version: "
+       @psql --version 2>/dev/null || echo "not installed"
+       @echo -n "  MySQL version: "
+       @mysql --version 2>/dev/null || echo "not installed"
        @echo
 
 Trac.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.

[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

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

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

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

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

[Ryan J Ollos]

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

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

[anonymous]

succeeded with the release candidate?

[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

[Ryan J Ollos]

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

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

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

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

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

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