<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:16:28 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[CDRIVER-2831] Migrate to dynamic VERSION_CURRENT</title>
                <link>https://jira.mongodb.org/browse/CDRIVER-2831</link>
                <project id="10030" key="CDRIVER">C Driver</project>
                    <description>&lt;p&gt;The application version is determined at build time by looking in &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt;.  That file is maintained manually.  In an effort to move toward a more automated process, this file should be generated by a script (using the same approach described in &lt;a href=&quot;https://jira.mongodb.org/browse/CXX-584&quot; title=&quot;Design C++11 driver release process&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CXX-584&quot;&gt;&lt;del&gt;CXX-584&lt;/del&gt;&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kevin.albertson&quot; class=&quot;user-hover&quot; rel=&quot;kevin.albertson&quot;&gt;kevin.albertson&lt;/a&gt;, as part of this I would like to eliminate &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; entirely.  The only use of it I found was in assembling the URL for GitHub tarball download.  Is there an alternative approach that would allow eliminating it?&lt;/p&gt;</description>
                <environment></environment>
        <key id="607964">CDRIVER-2831</key>
            <summary>Migrate to dynamic VERSION_CURRENT</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13201">Fixed</resolution>
                                        <assignee username="roberto.sanchez@mongodb.com">Roberto Sanchez</assignee>
                                    <reporter username="roberto.sanchez@mongodb.com">Roberto Sanchez</reporter>
                        <labels>
                    </labels>
                <created>Fri, 21 Sep 2018 12:34:48 +0000</created>
                <updated>Sat, 28 Oct 2023 11:29:35 +0000</updated>
                            <resolved>Thu, 27 Sep 2018 19:51:00 +0000</resolved>
                                                    <fixVersion>1.14.0</fixVersion>
                                    <component>libbson</component>
                    <component>libmongoc</component>
                                        <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="2155961" author="xgen-internal-githook" created="Tue, 19 Feb 2019 18:39:02 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;Kevin Albertson&apos;, &apos;username&apos;: &apos;kevinAlbs&apos;, &apos;email&apos;: &apos;kevin.albertson@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2831&quot; title=&quot;Migrate to dynamic VERSION_CURRENT&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2831&quot;&gt;&lt;del&gt;CDRIVER-2831&lt;/del&gt;&lt;/a&gt; don&apos;t use --sort&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/commit/f7353bc796d4bf98a43d1ea7d317b09173cc00a4&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/commit/f7353bc796d4bf98a43d1ea7d317b09173cc00a4&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2017099" author="xgen-internal-githook" created="Fri, 28 Sep 2018 01:03:38 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;Roberto C. S&#225;nchez&apos;, &apos;email&apos;: &apos;roberto@connexer.com&apos;, &apos;username&apos;: &apos;rcsanchez97&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2831&quot; title=&quot;Migrate to dynamic VERSION_CURRENT&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2831&quot;&gt;&lt;del&gt;CDRIVER-2831&lt;/del&gt;&lt;/a&gt; migrate to dynamic VERSION_CURRENT, 2&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/commit/55353fc040ef8202fcda0b56e2545536b640d340&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/commit/55353fc040ef8202fcda0b56e2545536b640d340&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2016813" author="xgen-internal-githook" created="Thu, 27 Sep 2018 19:39:33 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;Roberto C. S&#225;nchez&apos;, &apos;email&apos;: &apos;roberto@connexer.com&apos;, &apos;username&apos;: &apos;rcsanchez97&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2831&quot; title=&quot;Migrate to dynamic VERSION_CURRENT&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2831&quot;&gt;&lt;del&gt;CDRIVER-2831&lt;/del&gt;&lt;/a&gt; migrate to dynamic VERSION_CURRENT&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/commit/f5b49120348218d803e8b9ad9c83f21127a4b344&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/commit/f5b49120348218d803e8b9ad9c83f21127a4b344&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2013855" author="jesse" created="Tue, 25 Sep 2018 18:22:43 +0000"  >&lt;p&gt;We&apos;re following this spec:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/specifications/blob/0cf00e6ec2ebc1f8959d04c674623431b58198f1/source/mongodb-handshake/handshake.rst&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/blob/0cf00e6ec2ebc1f8959d04c674623431b58198f1/source/mongodb-handshake/handshake.rst&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;For diagnosis, first try a printf in&#160;_mongoc_handshake_build_doc_with_application where&#160;doc-&amp;gt;len &amp;gt; HANDSHAKE_MAX_SIZE, see what the handshake&apos;s JSON is so far before the function returns false.&lt;/p&gt;

&lt;p&gt;In&#160;test_mongoc_handshake_data_append_success, if any of the strstr checks fail, printf before aborting.&lt;/p&gt;

&lt;p&gt;The server &lt;b&gt;does&lt;/b&gt; enforce a 512-byte limit if we don&apos;t, so we can&apos;t increase the limit client-side.&#160;Once diagnosed, I liked your proposed workaround of just setting the handshake metadata version number to something like &quot;1.14.0-pre&quot;, without the extensive git info in the string. If that&apos;s hard for some reason, I propose a workaround with a private API used for testing that forces the version number to 1.2.3.&#160;&lt;/p&gt;</comment>
                            <comment id="2013493" author="roberto.sanchez" created="Tue, 25 Sep 2018 15:03:13 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kevin.albertson&quot; class=&quot;user-hover&quot; rel=&quot;kevin.albertson&quot;&gt;kevin.albertson&lt;/a&gt;, so I have run into a problem that is keeping me from being able to get this fully nailed down.  Specifically I encountered a failure in the &lt;tt&gt;/MongoDB/handshake/success&lt;/tt&gt; test, which I traced to the lengthened version string (recall that the approach for calculating the current version will now produce something like 1.14.0-20180925+git683f6ac059 for most builds).  That string is 30 characters long, while &lt;tt&gt;mongoc-handshake-private.h&lt;/tt&gt; defines &lt;tt&gt;HANDSHAKE_DRIVER_VERSION_MAX&lt;/tt&gt; as 32.  This pushes the canary that the unit test looks for almost entirely out of the version string, so much so that the call to &lt;tt&gt;strstr()&lt;/tt&gt; in the test is what fails.  So, I increased &lt;tt&gt;HANDSHAKE_DRIVER_VERSION_MAX&lt;/tt&gt; to 48, but then that caused parts of the handshake to not all fit, so then I increased &lt;tt&gt;HANDSHAKE_MAX_SIZE&lt;/tt&gt;, which resulted in this:&lt;/p&gt;


&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;error calling ismaster: &apos;The client metadata document must be less then or equal to 512bytes&apos;&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;


&lt;p&gt;Which takes me back to &lt;tt&gt;HANDSHAKE_DRIVER_VERSION_MAX&lt;/tt&gt;.  It appears that I cannot increase it past 32, so from a practical perspective, the test imposes a limit of 20 characters, because the call to &lt;tt&gt;strstr()&lt;/tt&gt; looks for the string &lt;tt&gt;&quot;version abc&quot;&lt;/tt&gt;.  The question is, do I modify the unit test?  Given that the new version scheme produces a 30 character version (31 if the patch version goes to two digits), what single character can I use as a canary?  Or, do I modify the version scheme?  I am reluctant to remove the Git commit ID, as that is very useful, but Git IDs are not well ordered (which is why I also include the date).  In any event, I could find a way to shave some characters off the version, but I would still need something shorter than &lt;tt&gt;&quot;version abc&quot;&lt;/tt&gt; as a canary.&lt;/p&gt;

&lt;p&gt;Thoughts?  Suggestions?&lt;/p&gt;</comment>
                            <comment id="2011496" author="jesse" created="Sun, 23 Sep 2018 20:07:37 +0000"  >&lt;p&gt;Let&#8217;s fall back to 0.0.0 and build successfully with a warning, for convenience. People &lt;b&gt;do&lt;/b&gt; want to check out and build from git, outside of MongoDB staff. Include in the warning: instructions for installing GitPython and running the script, or a pointer to where to read those instructions. &lt;/p&gt;</comment>
                            <comment id="2011384" author="roberto.sanchez" created="Sun, 23 Sep 2018 13:03:09 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, thanks for confirming the versioning scheme.&#160; The main thing I need to know now is whether it is OK to require manual invocation of the version calculation script by the user as an extra step prior to invoking CMake.&#160; This would only be required when building from Git, because the &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt; and &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; files will no longer be kept under version control.  If it is OK to require the invocation of the version calculation script, then the CMake message would change from a warning that the files cannot be found and that we are using version 0.0.0 to a fatal error telling the user to invoke the version calculation script.  For us in Evergeen this is not an issue at all since the tasks are themselves scripts and we can invoke arbitrary commands in any order we like, but I am not sure how you would view this as a requirement for users building from Git.  If it is not OK to require manual invocation of the version calculation script before CMake, then I will need to come up with a way refresh the variable assignments (the version variables and the variable that stores the name of the distribution tarball) whenever the dist or distcheck targets are invoked.  It is not immediately obvious to me how that would work, but I could give it a try.&lt;/p&gt;</comment>
                            <comment id="2011355" author="jesse" created="Sun, 23 Sep 2018 08:55:46 +0000"  >&lt;p&gt;Thanks Roberto. Your version calculation scheme sounds right to me for the C Driver, and it will match how we handle the C++ Driver branches and tags from now on.&lt;/p&gt;

&lt;p&gt;Right, it&apos;s ok to require Python to make a release archive: we already require Python and Sphinx for the docs portion, it&apos;s ok to require Python and GitPython to generate version numbers. As you say, building &lt;b&gt;from&lt;/b&gt; a release archive must not require Python.&lt;/p&gt;</comment>
                            <comment id="2011327" author="roberto.sanchez" created="Sun, 23 Sep 2018 04:12:27 +0000"  >&lt;p&gt;Assuming what I described in my previous comment is acceptable, the only remaining obstacle that I have to overcome is how to handle invocation of the &lt;tt&gt;dist&lt;/tt&gt; and &lt;tt&gt;distcheck&lt;/tt&gt; targets in the case where &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt; and &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; are not yet created.  I can make those targets depend on the creation of the files (same for the doc targets), but by the point that happens CMake has already failed to find the files and set the version variables to 0.0.0 and determined that the release archive will be called &lt;tt&gt;mongo-c-driver-0.0.0.tar.gz&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;The &quot;easy&quot; solution is to require that the version calculation script be called prior to invoking CMake.  Would that be acceptable? That would be something that would not be a problem in our Evergreen task.  Or is it necessary that the version and archive naming be handled completely when CMake and subsequently make are invoked from a Git working directory?  (This is not an issue when invoked from within a release archive, as we will ship those files in the archive.)&lt;/p&gt;</comment>
                            <comment id="2011322" author="roberto.sanchez" created="Sun, 23 Sep 2018 03:06:21 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kevin.albertson&quot; class=&quot;user-hover&quot; rel=&quot;kevin.albertson&quot;&gt;kevin.albertson&lt;/a&gt;, so I have been looking at the algorithm I implemented for calculating the version number to try to determine if there is a short circuit path to get to the previous release version (what would be stored in &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt;).  I have concluded that such a path does not exist in the current implementation of the version calculation script.  To further inform my analysis I examined the &lt;tt&gt;abi-compliance-check.sh&lt;/tt&gt; script and found that there is an assumption (perhaps implied) that the version number contained in &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; will always correspond to a tag in Git.  The command &lt;tt&gt;git checkout tags/$newest -f&lt;/tt&gt; in the script supports my conclusion.&lt;/p&gt;

&lt;p&gt;Additionally, it is clear that an additional special case must be considered when determining the previous release version: the version may be derived from a tag another branch.  For example, when 1.10.0 was released, the previous version was 1.9.5, derived from a tag along the r1.9 branch.&lt;/p&gt;

&lt;p&gt;Armed with all of the above I determined what I believe to be the simplest reliable approach that ensures we always find the correct previous version.  Simply stated: the previous version is defined as the version represented by the latest git tag matching the regular expression &lt;tt&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0-9&amp;#93;&lt;/span&gt;&amp;#43;\.&lt;span class=&quot;error&quot;&gt;&amp;#91;0-9&amp;#93;&lt;/span&gt;&amp;#43;\.&lt;span class=&quot;error&quot;&gt;&amp;#91;0-9&amp;#93;&lt;/span&gt;&amp;#43;&lt;/tt&gt; and which is strictly a lower version than the version calculated for &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt;.  (Note that this specifically includes pre-release tags, as I could no evidence that &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; has ever contained a pre-release version.  It also considers every tag in Git instead of traversing back in history from the current point.)&lt;/p&gt;

&lt;p&gt;So, for example, I am currently working on a topic branch and the version calculation for the current version produces the version number 1.11.1-20180922+git67e3e5215e, which would correspond to a previous release version of 1.11.0.  For master, the current version is calculated as 1.14.0-20180922+git67e3e5215e, which would correspond to a previous version of 1.13.0, which makes sense.  Then, for the r1.13 branch at commit 6afb83ef8, which corresponds to the 1.13.0 tag, the current version calculation is 1.13.0 and the previous version is 1.12.0 (which originates from another branch entirely).  This last scenario would be what we would expect for a final release build for 1.13.0.&lt;/p&gt;

&lt;p&gt;Based on all of this, the recommended command line flag (I am thinking of &lt;tt&gt;-p&lt;/tt&gt; for previous or prior) would calculate the current version (as is done without the option) and then additionally locate the appropriate tag in the manner I described above.  The output of the script would then be the tag that represents the previous version.&lt;/p&gt;

&lt;p&gt;Does this approach seem like it will do what we need?&lt;/p&gt;</comment>
                            <comment id="2010342" author="roberto.sanchez" created="Fri, 21 Sep 2018 14:13:10 +0000"  >&lt;p&gt;OK.  I&apos;ll make the necessary modifications.&lt;/p&gt;</comment>
                            <comment id="2010328" author="kevin.albertson" created="Fri, 21 Sep 2018 14:08:07 +0000"  >&lt;p&gt;Right, we use it for calculating the tarball URL info in docs in the Sphinx configuration: &lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/blob/r1.13/src/libmongoc/doc/conf.py&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;conf.py&lt;/a&gt;&lt;br/&gt;
We also use it for the automated ABI checking script: &lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/blob/r1.13/.evergreen/abi-compliance-check.sh#L18&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;abi-compliance-check.sh&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Before adding it to the C driver, could we modify the calc_release_version.py script to also print the most recent release version given some flag (without bumping it)? Both cases could use that python script to determine the most recent release.&lt;/p&gt;</comment>
                            <comment id="2010287" author="jesse" created="Fri, 21 Sep 2018 13:39:04 +0000"  >&lt;p&gt;Great. If that&#8217;s all we use VERSION_RELEASED for, then we only use it in a&lt;br/&gt;
context where we can rely on Python (when building docs with Sphinx). I&lt;br/&gt;
think we can add GitPython to the list of deps for building docs, and&lt;br/&gt;
calculate the version while building them.&lt;/p&gt;

&lt;p&gt;On Fri, Sep 21, 2018 at 8:35 AM Roberto Sanchez (Jira) &amp;lt;jira@mongodb.org&amp;gt;&lt;/p&gt;
</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>CDRIVER-2845</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|htyz5z:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>