<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:59:39 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>[CXX-584] Design C++11 driver release process</title>
                <link>https://jira.mongodb.org/browse/CXX-584</link>
                <project id="11980" key="CXX">C++ Driver</project>
                    <description>&lt;p&gt;We have never issued a release from the master branch. We need to figure out what our release process is, and how it integrates with the build system. If possible, I&apos;d like to use a git-describe based workflow, rather than bump/post commits. If we do that, we need to figure out how to make source packages, and how that would work with githubs source tarball generation.&lt;/p&gt;</description>
                <environment></environment>
        <key id="199591">CXX-584</key>
            <summary>Design C++11 driver release process</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</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="9">Done</resolution>
                                        <assignee username="roberto.sanchez@mongodb.com">Roberto Sanchez</assignee>
                                    <reporter username="andrew.morrow@mongodb.com">Andrew Morrow</reporter>
                        <labels>
                    </labels>
                <created>Wed, 22 Apr 2015 16:12:21 +0000</created>
                <updated>Tue, 9 Jul 2019 21:21:44 +0000</updated>
                            <resolved>Mon, 12 Nov 2018 14:31:27 +0000</resolved>
                                                    <fixVersion>3.5.0</fixVersion>
                                    <component>Release</component>
                                        <votes>0</votes>
                                    <watches>6</watches>
                                                                                                                <comments>
                            <comment id="2058591" author="xgen-internal-githook" created="Mon, 12 Nov 2018 14:29:03 +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/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; remove non-existent file from dist manifest&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-cxx-driver/commit/f96764be682cda389d066b44fc3a1caf20711683&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-cxx-driver/commit/f96764be682cda389d066b44fc3a1caf20711683&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2058515" author="xgen-internal-githook" created="Mon, 12 Nov 2018 13:22:39 +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/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; implement dist/distcheck targets&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-cxx-driver/commit/22b9e90f6fa0c9529898e1c4efa0a3828b89e08d&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-cxx-driver/commit/22b9e90f6fa0c9529898e1c4efa0a3828b89e08d&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2034467" author="roberto.sanchez" created="Wed, 17 Oct 2018 13:32:54 +0000"  >&lt;p&gt;It looks like the last remaining discrete task in order to close out this ticket is the implementation of dist/distcheck targets that allow creation of the upstream tarball (similar to what is done in the C Driver).&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=acm&quot; class=&quot;user-hover&quot; rel=&quot;acm&quot;&gt;acm&lt;/a&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;, do you agree?&lt;/p&gt;</comment>
                            <comment id="2034464" author="xgen-internal-githook" created="Wed, 17 Oct 2018 13:28:42 +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/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; implement loading of release version from file&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-cxx-driver/commit/a1d3d2da4cef22641841746767421cbaaef4b9fd&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-cxx-driver/commit/a1d3d2da4cef22641841746767421cbaaef4b9fd&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2034463" author="xgen-internal-githook" created="Wed, 17 Oct 2018 13:28:40 +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/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; implement script to calculate release version&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-cxx-driver/commit/66c47d586c9ca4cedfb93617f67c32d41217caa7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-cxx-driver/commit/66c47d586c9ca4cedfb93617f67c32d41217caa7&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2025035" author="acm" created="Fri, 5 Oct 2018 14:39:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=roberto.sanchez&quot; class=&quot;user-hover&quot; rel=&quot;roberto.sanchez&quot;&gt;roberto.sanchez&lt;/a&gt; - I agree the tarballs should know their version, but I expected that CMake would drive the source tarball creation. I think it sounds like we are going to meet in the middle on this one overall, and that is fine. It is definitely a step forward from where we are now.&lt;/p&gt;</comment>
                            <comment id="2024825" author="roberto.sanchez" created="Fri, 5 Oct 2018 11:42:34 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=acm&quot; class=&quot;user-hover&quot; rel=&quot;acm&quot;&gt;acm&lt;/a&gt;, after discussing this with &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; he has captured most of my thoughts on this.  I am just going to add a few additional details.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;The reasoning for reading &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt; if available (and also &lt;tt&gt;VERSION_RELEASED&lt;/tt&gt; in the C driver) is that a release tarball should always know its own version number without the user being required to specify it; the release process for both drivers will require generating that file for distribution in the release tarball&lt;/li&gt;
	&lt;li&gt;I like your idea of invoking &lt;tt&gt;calc_release_version.py&lt;/tt&gt; from within CMake if, as Jesse indicated, neither &lt;tt&gt;VERSION_CURRENT&lt;/tt&gt; is available nor the version specified via environment/CMake variables&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I will work on making the necessary changes and post them for review.&lt;/p&gt;

&lt;p&gt;Jesse and I also discussed that once these changes are finalized I will work on integrating the improvements into the C driver.&lt;/p&gt;</comment>
                            <comment id="2020943" author="jesse" created="Tue, 2 Oct 2018 18:17:05 +0000"  >&lt;p&gt;From conversation w/ Roberto:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Agreed we&apos;ll add a &quot;MONGOCXX_VERSION&quot; CMake option (we&apos;ll just assume BSONCXX_VERSION is always equal)&lt;/li&gt;
	&lt;li&gt;If that option&apos;s not set, CMake will try to load the VERSION_CURRENT file&lt;/li&gt;
	&lt;li&gt;Agreed, we&apos;ll keep the Python script as a fallback if that option isn&apos;t set and the file is absent. CMake&apos;s execute_process() calls the script.&lt;/li&gt;
	&lt;li&gt;If Python or GitPython are absent or some other error, set version to 0.0.0, with a warning.&lt;/li&gt;
	&lt;li&gt;Agreed that the LoadVersion script is renamed ParseVersion, it now reads the MONGOCXX_VERSION set from command line or Python script output&lt;/li&gt;
	&lt;li&gt;However, let&apos;s &lt;b&gt;allow&lt;/b&gt; users to succeed building with version 0.0.0: Even if they don&apos;t set the option from the command line and they don&apos;t have Python, they should succeed. Update CMake&apos;s warning to advise they set MONGOCXX_VERSION option or else make Python and GitPython available.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="2020803" author="acm" created="Tue, 2 Oct 2018 16:43:10 +0000"  >&lt;p&gt;Replying to &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; -&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;If we prohibited building with version 0.0.0, then someone cloning the repo would be unable to build without first running calc_release_version.py or explicitly providing the version number.&lt;/p&gt;

&lt;p&gt;That would be resolved by rewriting the logic of calc_release_version.py in CMake. But I&apos;d prefer not having to rewrite that in CMake.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Not necessarily. You could keep &lt;tt&gt;calc_release_version.py&lt;/tt&gt;, but simply teach CMake to invoke it to generate a target that was the result of running calc_release_version.py. You could keep most of the logic in python.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Plus, if someone cloned without the git history (e.g. with --depth=1) or downloads a zip of the source, they&apos;d always have to provide an explicit version number.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;If they cloned with --depth=1, then yes, they would need to provide an explicit version number. But that is what they asked for! I really think it is dangerous to allow people to produce builds with a version of &lt;/p&gt;
{0.0.0}
&lt;p&gt;. End users do build from source, and we need to be able to ask for the version that they are running and ensure we can always get a meaningful answer. Regarding a zip file, I&apos;d assume that any source distributions we produce would also be managed through CMake (I believe the C driver already does this), and could leverage the same mechanisms.&lt;/p&gt;

&lt;p&gt;Replying to &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;/p&gt;

&lt;blockquote&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The Python is already written&lt;/li&gt;
	&lt;li&gt;The Python is maintainable: a random programmer is more likely to understand moderately complex logic in Python than in CMake&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;

&lt;p&gt;See my thoughts above. You could I think still keep most of the python, but still drive its invocation through CMake.&lt;/p&gt;

&lt;blockquote&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The 0.0.0 version number prevents mistakes: a dependent project that requires a version number (and later, an ABI number) won&apos;t accept 0.0.0&lt;/li&gt;
	&lt;li&gt;The CMake script prints instructions for how to run the Python script&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;

&lt;p&gt;I sort of disagree, because I&apos;d consider any build that ended up with 0.0.0 to be a mistake. People build from source all the time. &lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;So let&apos;s declare victory with the current setup.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Up to you of course.&lt;/p&gt;</comment>
                            <comment id="2020619" author="jesse" created="Tue, 2 Oct 2018 15:04:50 +0000"  >&lt;p&gt;Drew, your proposal is attractive and I almost agreed when I first read it. But I think that:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;The Python is already written&lt;/li&gt;
	&lt;li&gt;The Python is maintainable: a random programmer is more likely to understand moderately complex logic in Python than in CMake&lt;/li&gt;
	&lt;li&gt;The 0.0.0 version number prevents mistakes: a dependent project that requires a version number (and later, an ABI number) won&apos;t accept 0.0.0&lt;/li&gt;
	&lt;li&gt;The CMake script prints instructions for how to run the Python script&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;So let&apos;s declare victory with the current setup.&lt;/p&gt;</comment>
                            <comment id="2020562" author="kevin.albertson" created="Tue, 2 Oct 2018 14:40:01 +0000"  >&lt;p&gt;If we prohibited building with version 0.0.0, then someone cloning the repo would be unable to build without first running calc_release_version.py or explicitly providing the version number.&lt;/p&gt;

&lt;p&gt;That would be resolved by rewriting the logic of calc_release_version.py in CMake. But I&apos;d prefer not having to rewrite that in CMake.&lt;/p&gt;

&lt;p&gt;Plus, if someone cloned without the git history (e.g. with &lt;tt&gt;--depth=1&lt;/tt&gt;) or downloads a zip of the source, they&apos;d always have to provide an explicit version number.&lt;/p&gt;</comment>
                            <comment id="2019508" author="roberto.sanchez" created="Mon, 1 Oct 2018 18:13:46 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=acm&quot; class=&quot;user-hover&quot; rel=&quot;acm&quot;&gt;acm&lt;/a&gt;, thanks!  I will try to digest this and provide a response later today.&lt;/p&gt;</comment>
                            <comment id="2019236" author="acm" created="Mon, 1 Oct 2018 15:43:03 +0000"  >&lt;p&gt;Per request from &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;, I&apos;m copying my overall thoughts on the approach taken so far, so that we can consider whether we want to adopt none, some, or all of my suggestions:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;My first suggestion is that I would remove the file reading from &lt;tt&gt;LoadVersion&lt;/tt&gt;, and rename it to &lt;tt&gt;ParseVersion&lt;/tt&gt;. I would then define new CMake flags for the command line called &lt;tt&gt;MONGOCXX_VERSION&lt;/tt&gt; and &lt;tt&gt;BSONCXX_VERSION&lt;/tt&gt;. Then use &lt;tt&gt;ParseVersionto&lt;/tt&gt; decompose those into the version subcomponents.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;If you do the above, then do the build process as follows:
&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;   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;python etc/calc_release_version.py &amp;gt; build/VERSION_CURRENT&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;cd build&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;cmake -DMONGOCXX_VERSION=$(cat VERSION_CURRENT) -DBSONCXX_VERSION=$(cat&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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-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;VERSION_CURRENT) ...&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;I&apos;d do this because that way people who are not us who are packaging the driver can set the version to whatever works for them, in the event that the {{calc_release_version} script isn&apos;t appropriate for their needs.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;I would also simply refuse to build if a version was not provided, or one was provided that didn&apos;t parse. We don&apos;t want people building and getting 0.0.0, and that definitely &lt;b&gt;will&lt;/b&gt; happen if we allow builds to go forward without a version.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Next, and this is admittedly harder, I think I would try to eliminate the python script entirely, and instead do the git machinery and derivation inside&lt;br/&gt;
CMake. In particular, I would do it in a way that would be respected inside the generated build system, such that if you were to edit, build, commit, tag, and re-build, say with ninja, you would get the updated version on the rebuild. The version computed this way would only be used if explicit values for {&lt;tt&gt;MONGO,BSON}CXX_VERSION&lt;/tt&gt; were not provided. Overall, I think it is important that simply running
&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;   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;git clone ...&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;cd build&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;cmake ..&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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-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;make all &amp;amp;&amp;amp; make install&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;gets you a valid version with no other steps or flags needed.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;On additional thing to consider is that I think we are also going to want a tag based mechanism for bumping ABI.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="1999806" author="jesse" created="Tue, 11 Sep 2018 18:33:32 +0000"  >&lt;p&gt;Sounds good to me!&lt;/p&gt;</comment>
                            <comment id="1999564" author="roberto.sanchez" created="Tue, 11 Sep 2018 16:20:04 +0000"  >&lt;p&gt;So, here is what I am thinking.  The algorithm would look like this:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;Is the current branch master?&lt;/li&gt;
	&lt;li&gt;If yes the current branch is master, then inspect the branches that fit the convention for a release branch and choose the latest; increment the minor version and append &lt;tt&gt;.0&lt;/tt&gt; to form the new version (e.g., releases/v3.3 becomes 3.4.0) and append a pre-release marker (I favor one based on the Git commit ID)&lt;/li&gt;
	&lt;li&gt;If no the current branch is not master, then use the git tag command you suggested to determine the most recent tag in history; strip any pre-release marker, increment the patch version and append a new pre-release marker&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Once the version has been determined, place the version number in a file which will be distributed with the release tarball.  The CMakeLists.txt will then be modified to load the version number from this file.&lt;/p&gt;

&lt;p&gt;This makes it so that any build of off master will have a pre-release version later than the latest release branch.  The only &quot;bad&quot; think about this approach is that if you check out to an old commit on master (that still has these changes implemented), then you could end up with a version number that seems &quot;too new.&quot;  However, the easy workaround is to checkout the commit to a new local branch and work from there, then the logic of the algorithm will produce sensible results.&lt;/p&gt;

&lt;p&gt;I thought about all sorts other possibilities including walking backward in history to find the most recent branch and use that to help determine the version number.  However, it quickly became over-complicated.  As I tried to simplify and limit the scope of the problem we are trying to solve, I came with &quot;builds from the HEAD of master and the HEAD of each release branch should produce sensible version numbers.&quot;  Depending on the details of the tagging strategy and where topic branches get created, we may end up with some weird version numbers getting generated for topic branches, but that seems OK.  If we decide we want sensible numbers on a topic branch, it is as simple as manually tagging some spot in its history with an appropriate version number that allows the algorithm to produce something sensible.&lt;/p&gt;

&lt;p&gt;In any event, we can discuss the details in more depth if any of this seems unclear.&lt;/p&gt;</comment>
                            <comment id="1999236" author="roberto.sanchez" created="Tue, 11 Sep 2018 13:24:27 +0000"  >&lt;p&gt;So, I have looked at this I think that your suggestion could be improved.  I have some ideas that I am working on and I will write them up here in another comment or discuss them with you on the call (depending on which happens first).&lt;/p&gt;</comment>
                            <comment id="1998163" author="jesse" created="Mon, 10 Sep 2018 16:26:42 +0000"  >&lt;p&gt;Whatever the process has been for C++ so far, I expect we&apos;ll now follow for both projects the following process for minor releases:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;branch from master&lt;/li&gt;
	&lt;li&gt;make a few commits with final preparations for a minor release&lt;/li&gt;
	&lt;li&gt;tag the release on the branch: for C, that&apos;s a &quot;1.2.3&quot; tag on &quot;r1.2&quot; branch, for C++ that&apos;s a &quot;r1.2.3&quot; tag on &quot;releases/v1.2&quot; branch&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;For patch releases:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;make a few commits on the branch (&quot;r1.2&quot; or &quot;releases/v1.2&quot;) to fix bugs&lt;/li&gt;
	&lt;li&gt;tag the release on the branch: &quot;1.2.4&quot; on &quot;r1.2&quot; for C, &quot;r1.2.4&quot; on &quot;releases/v1.2&quot; for C++&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;m fine with the idea of sensible version numbers. You could get the latest actual release on this branch like:&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;   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;# C Driver&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;git tag --merged HEAD --list &apos;1.*&apos; --sort &apos;version:refname&apos; | tail -n 1&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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;   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;# C++&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&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-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;git tag --merged HEAD --list &apos;r*&apos; --sort &apos;version:refname&apos; | tail -n 1&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;... and then generate the next version. I suggest a Python script for that logic if the Bash for it isn&apos;t legible.&lt;/p&gt;</comment>
                            <comment id="1997797" author="roberto.sanchez" created="Mon, 10 Sep 2018 14:23:29 +0000"  >&lt;p&gt;We can probably make it work with dummy version numbers, but we will need to come up with a way to programmatically distinguish release commits from non-release commits.  As long as the workflow is &quot;tag the .0 release on master and then branch&quot; it should never be an issue.  We would be able to apply a simple and consistent algorithm for determining the &quot;next&quot; version and we would not need dummy version numbers.  The advantage to doing that over using a non-related dummy version is that it will allow looking back historically to make sense by comparing version numbers of builds along different branches.  The advantage of dummy version numbers is that we would never accidentally mistake them for a release (though I think such a mistake would be highly unlikely).  I favor sensible version numbers over dummy version numbers, but only if the release workflow supports the tag-then-branch strategy I described.&lt;/p&gt;</comment>
                            <comment id="1997681" author="jesse" created="Mon, 10 Sep 2018 12:57:02 +0000"  >&lt;p&gt;Thanks Roberto. Does it matter what version number we choose when building the driver from a non-release commit, or during a patch build? Could we say &quot;if this commit is not tagged as a release, or if this is a patch build, the version number is 1.2.3&quot;? I don&apos;t think version numbers need to be unique: one Evergreen task doesn&apos;t care if another Evergreen task used the same version number. I also don&apos;t think the version number must be greater than all actual releases.&lt;/p&gt;

&lt;p&gt;If it is important to generate a release number greater than previous ones we could choose 100.0.0. Tell me if I&apos;m missing something!&lt;/p&gt;</comment>
                            <comment id="1997255" author="roberto.sanchez" created="Sun, 9 Sep 2018 04:10:26 +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;, I have read the ticket summary and Drew&apos;s proposal as well.  The outline you provided is on target.&lt;/p&gt;

&lt;p&gt;The only thing that I would point out as far as the versioning based on &quot;git describe&quot; is that it is sensitive to tag location.  What I mean is that version numbering could be a bit wonky on master if the release tags end up on the branch (as is the case with the 1.12.0 tag for the C Driver).  For example, &lt;tt&gt;git describe --tags&lt;/tt&gt; on C Driver&apos;s master branch gives me this: 1.11.0-215-g6ea7737dc.  That seems wrong to me since 1.12.0 is out and we currently have a 1.13.0-dev pre-release version on master.&lt;/p&gt;

&lt;p&gt;The C++ driver is in slightly better shape.  The r3.3.0 tag was made on a commit that is a linear ancestor of master, so the describe output there is more sensible: r3.3.0-42-gca7eee19c.  However, the r3.3.1 tag was made on a branch.&lt;/p&gt;

&lt;p&gt;It is clear that for an actual release that the describe output will work nicely.  However, I am curious about what strategy we should use to handle version numbers for commits after a release (i.e., since version 3.3.0 of C++ driver has been release, should builds from the current master use a &quot;next&quot; pre-release version of some sort?).&lt;/p&gt;

&lt;p&gt;There is also the matter of how to handle versioning for Evergreen patch builds.  For example, If you tag 3.4.0, then we can easily determine that the version is 3.4.0 and fill the variables appropriately.  However, all the Evergreen patch builds with that commit as their base will also have version 3.4.0.  Should our strategy account for that and use the &quot;next pre-release&quot; version for those builds as well?&lt;/p&gt;

&lt;p&gt;Along with the &quot;next pre-release&quot; version concept, we need to decide if the &quot;next&quot; is different depending on whether we are on master or another branch.  For example, I can see that on master &quot;next&quot; might be 3.4.0-pre-something, while on releases/v3.3 it might be 3.3.2-pre-something.&lt;/p&gt;

&lt;p&gt;Once we have sort these things out, I can start implementing a solution.&lt;/p&gt;

&lt;p&gt;After that is done, it should be straightforward to adapt the MakeDist components from the C driver to work with the C++ Driver repository.&lt;/p&gt;</comment>
                            <comment id="1996796" author="jesse" created="Fri, 7 Sep 2018 20:02:27 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=roberto.sanchez&quot; class=&quot;user-hover&quot; rel=&quot;roberto.sanchez&quot;&gt;roberto.sanchez&lt;/a&gt; when you&apos;re ready to start on this, I think the first steps are:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Read Drew&apos;s proposal, above.&lt;/li&gt;
	&lt;li&gt;Write CMake script to set the version number in BSONCXX_VERSION_MAJOR etc. from &quot;git describe&quot;. I declare that the bsoncxx and mongocxx version numbers will always be the same for a given commit, so we can just take the version number for both from the git tag.&lt;/li&gt;
	&lt;li&gt;Generate a release archive for the C++ Driver using CMake, similar to how we do it for the C Driver.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I realize we&apos;re adding the same features to the C and C++ driver release scripts but in adding them in a different order. We can rationalize this as we go along.&lt;/p&gt;</comment>
                            <comment id="1135116" author="acm" created="Thu, 14 Jan 2016 17:09:01 +0000"  >&lt;p&gt;We are using the BUMP/post release style for the 3.0 GA. For 3.1.0, I&apos;d like us to move to &apos;bumpless&apos; releases where we use git-describe to generate the version number. However, this isn&apos;t required for 3.0.0.&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>CXX-1676</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrdsxb:</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>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="476">Platform 2 04/24/15</customfieldvalue>
    <customfieldvalue id="1309">Platforms 2016-10-10</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>