<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Hey Colin,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">That’s similar to my original suggestion. I was saying we just have a global for “fluid” instead of “fluid_version”. I think defining “fluid” as a global in the shared config should work for most projects using Infusion. I suppose it could be an issue for projects that don’t, but they could override that in their own config.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Thanks</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Justin</div> <div id="bloop_sign_1484758836205522944" class="bloop_sign"></div> <br><p class="airmail_on">On January 18, 2017 at 11:50:01 AM, Colin Clark (<a href="mailto:colinbdclark@gmail.com">colinbdclark@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap:break-word" class=""><div></div><div>



<title></title>


Hi all,
<div class=""><br class=""></div>
<div class="">Perhaps I'm confused here, but it seems to me that
the eslint-config-fluid module is used by a variety of projects,
not just by Infusion. I use it in some of my personal libraries,
and it may also be used in the GPII? If that's the case, I don't
think it needs to make reference the fluid_x_y_z version global at
all; this is an internal aspect of Infusion itself. Shouldn't it be
defined in Infusion's own .eslintrc.json, rather than in the shared
configuration?</div>
<div class=""><br class=""></div>
<div class="">If that's the case, we won't have to worry about
synchronizing releases between two separate modules because they
will be, well, separate. :)</div>
<div class=""><br class=""></div>
<div class="">In other words, this shouldn't exist:</div>
<div class=""><br class=""></div>
<div class=""><a href="https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L7" class="">https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L7</a></div>
<div class=""><br class=""></div>
<div class="">It need only be here:</div>
<div class=""><br class=""></div>
<div class=""><a href="https://github.com/fluid-project/infusion/blob/master/.eslintrc.json#L4" class="">https://github.com/fluid-project/infusion/blob/master/.eslintrc.json#L4</a></div>
<div class=""><br class=""></div>
<div class="">I think maybe this was your original suggestion, am I
right Justin?</div>
<div class=""><br class=""></div>
<div class="">Colin</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 17, 2017, at 4:28 AM, Tony Atkins <<a href="mailto:tony@raisingthefloor.org" class="">tony@raisingthefloor.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi, Justin.
<div class=""><br class=""></div>
<div class="">The eslint-config-fluid project itself has versioned
releases, so it's mainly a matter of nicely coupling them to an
appropriate infusion release, and then making it clear how to
override the setting in individual projects.  IMO the latest
release of the eslint-config-fluid project should refer to the
latest major infusion release, which is the baseline.  If a
project is only compatible with a later minor/patch release (or
fluid 1.5), that setting can be overridden in the same
eslintrc.json file that brings in the eslint-config-fluid settings,
and details on doing so should be in the README of
eslint-config-fluid.<br class=""></div>
<div class=""><br class=""></div>
<div class="">To summarize, I'm proposing we leave the version
reflected in the eslint-config-fluid global settings at fluid_2_0_0
until 3.0 is released, and document how to override the setting in
the project's README.</div>
<div class=""><br class=""></div>
<div class="">Cheers,</div>
<div class=""><br class=""></div>
<div class=""><br class=""></div>
<div class="">Tony</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Mon, Jan 16, 2017 at 6:28 PM, Justin
Obara <span dir="ltr" class=""><<a href="mailto:obara.justin@gmail.com" target="_blank" class="">obara.justin@gmail.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div id="m_-5810860281771906670bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">One more thing to think about in relation to this issue.
What should we do about our eslint configuration. In
eslint-config-fluid right now we have a globals declaration
for <a href="https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L6-L8" target="_blank" class="">fluid_2_0_0</a>. I’m thinking that this
isn’t correct. Maybe we define a global for “fluid” and then each
project should add a specific version to define as a global as
needed. Most likely, this will just be in infusion itself.</div>
<div id="m_-5810860281771906670bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">Thanks</div>
<div id="m_-5810860281771906670bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="HOEnZb"><font color="#888888" class="">Justin</font></span></div>
<div class="">
<div class="h5"><br class="">
<div id="m_-5810860281771906670bloop_sign_1484587591425889024" class="m_-5810860281771906670bloop_sign"></div>
<br class="">
<p class="m_-5810860281771906670airmail_on">On January 13, 2017 at
7:36:53 AM, Justin Obara (<a href="mailto:obara.justin@gmail.com" target="_blank" class="">obara.justin@gmail.com</a>) wrote:</p>
<blockquote type="cite" class="m_-5810860281771906670clean_bq">
<div style="word-wrap:break-word" class="">
<div class=""></div>
<div class="">
<div id="m_-5810860281771906670bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">+1 to Colin and Tony’s latest
suggestions.</span></div>
<span class=""><br class=""></span>
<div id="m_-5810860281771906670bloop_sign_1484310973663785984" class="m_-5810860281771906670bloop_sign"></div>
<span class=""><br class=""></span>
<p class="m_-5810860281771906670airmail_on"><span class="">On
January 13, 2017 at 5:29:54 AM, Tony Atkins (<a href="mailto:tony@raisingthefloor.org" target="_blank" class="">tony@raisingthefloor.org</a>) wrote:</span></p>
<blockquote type="cite" class="m_-5810860281771906670clean_bq">
<div class="">
<div class="">
<div dir="ltr" class=""><span class=""><span class="">Hi,
Colin:</span></span>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Updating master to a future major
release version and cutting minor/patch/releases manually seems
like a good balance to me.  We should talk again as a group if
we find ourselves cutting minor/patch releases often enough that
merging becomes a burden.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Cheers,</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Tony</span></div>
</div>
<div class="gmail_extra"><span class=""><br class=""></span>
<div class="gmail_quote"><span class="">On Thu, Jan 12, 2017 at
10:48 PM, Colin Clark <span dir="ltr" class=""><<a href="mailto:colinbdclark@gmail.com" target="_blank" class="">colinbdclark@gmail.com</a>></span> wrote:<br class=""></span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">Hi all,
<div class=""><br class=""></div>
<div class="">I wonder if we can find a compromise that is
sufficiently low-maintenance and informal but still clear to our
users and at least within the spirt of semver? Given that we're a
small community with very ambitious goals and limited resources, we
should in general try to favour processes that are as informal and
easy to manage as possible.</div>
<div class=""><br class=""></div>
<div class="">How about this...?</div>
<div class=""><br class=""></div>
<div class="">1. Always keep the version of master set to the next
major release number. So, since we've released 2.0.0, master should
be set up to publish development releases for 3.0.0. When we
eventually cut 3.0.0, it will be incremented to 4.0.0, and so on.
The reality is that we know we're going be moving fast and making
lots of big changes over the next while as new framework features
emerge (such as the new Renderer), so we might as well assume that
our next release will be a major one.</div>
<div class=""><br class=""></div>
<div class="">2. If we do find the need to cut a smaller 2.0.y or a
2.x.y maintenance release due to major bugs or features, we simply
do what we've done in the past and use a release branch, apply or
back port any fixes we need into this branch when the demand builds
up, and then cut a release as needed.</div>
<div class=""><br class=""></div>
<div class="">I think this is essentially doing Justin's bullet #3
below, and only that. I don't think it's realistic to try to keep
three separate branches in sync all the time. That seems like a
recipe for mistakes and more release bureaucracy.</div>
<div class=""><br class=""></div>
<div class="">And yes, Tony's point about not deleting releases
makes a lot of sense.</div>
<div class=""><span class="m_-5810860281771906670HOEnZb"><font color="#888888" class=""><br class=""></font></span></div>
<div class=""><span class="m_-5810860281771906670HOEnZb"><font color="#888888" class="">Colin</font></span></div>
<div class="">
<div class="m_-5810860281771906670h5">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 11, 2017, at 11:04 AM, Justin Obara
<<a href="mailto:obara.justin@gmail.com" target="_blank" class="">obara.justin@gmail.com</a>> wrote:</div>
<br class="m_-5810860281771906670m_-3602002873625389210Apple-interchange-newline">

<div class="">
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class="">I’ve filed a task in JIRA for this work/discussion.</div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><a href="https://issues.fluidproject.org/browse/FLUID-6105" target="_blank" class="">https://issues.fluidproject.or<wbr class="">g/browse/FLUID-6105</a></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class="">Thanks</div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class="">Justin</div>
<br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div id="m_-5810860281771906670m_-3602002873625389210bloop_sign_1484150654950680064" class="m_-5810860281771906670m_-3602002873625389210bloop_sign" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</div>
<br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<p class="m_-5810860281771906670m_-3602002873625389210airmail_on" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
On January 9, 2017 at 11:57:48 AM, Justin Obara (<a href="mailto:obara.justin@gmail.com" target="_blank" class="">obara.justin@gmail.com</a>) wrote:</p>
<blockquote type="cite" class="m_-5810860281771906670m_-3602002873625389210clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div style="word-wrap:break-word" class="">
<div class="">
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">Hi Tony,</span></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class=""><br class=""></span></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">Warning and using the deprecated command
sound like a good approach.</span></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class=""><br class=""></span></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">Thanks</span></div>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><span class="">Justin</span></div>
<span class=""><br class=""></span>
<div id="m_-5810860281771906670m_-3602002873625389210bloop_sign_1483980996908059136" class="m_-5810860281771906670m_-3602002873625389210bloop_sign">
</div>
<span class=""><br class=""></span>
<p class="m_-5810860281771906670m_-3602002873625389210airmail_on">
<span class="">On January 9, 2017 at 11:41:56 AM, Tony Atkins
(<a href="mailto:tony@raisingthefloor.org" target="_blank" class="">tony@raisingthefloor.org</a>) wrote:</span></p>
<blockquote type="cite" class="m_-5810860281771906670m_-3602002873625389210clean_bq">
<div class="">
<div class="">
<div dir="ltr" class=""><span class=""><span class="">Hi,
Justin:</span></span>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I will wait for others to way in
further on the branching strategy, but I wanted to respond to this
point:</span></div>
<div class=""><span class=""><br class=""></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<ul style="font-size:12.8px" class="">
<li style="margin-left:15px" class=""><span class="">Potentially
clean up the erroneous dev builds by deleting them ( if we can get
away with that ), just the ones post 2.0 that were
wrong.</span></li>
</ul>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Deleting dev releases is a bad
practice, and much more trouble than confusing semver
ordering.  Builds that rely on the version would break on the
next commit or test run, for starters.  Package authors would
have to update before they can resume even testing their own
work.  This kind of unplanned disruption can cause chaos even
if you're just talking about the handful of people who use dev
builds within our community.  It's better to warn everyone and
move forward than to potentially and confusingly break work in
progress.  Even <a href="https://docs.npmjs.com/cli/unpublish" target="_blank" class="">npm
themselves strongly discourage unpublishing versions</a> in
the documentation for the command used to do so.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I can see a lot of other strategies
here that would accomplish the major goal (avoiding confusion
between pre and post release), for example, flagging the pre-2.0
releases as deprecated (which is what npm suggests).</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Cheers,</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Tony</span></div>
</div>
<div class="gmail_extra"><span class=""><br class=""></span>
<div class="gmail_quote"><span class="">On Mon, Jan 9, 2017 at 4:13
PM, Justin Obara<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:obara.justin@gmail.com" target="_blank" class="">obara.justin@gmail.com</a>></span><span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"><wbr class=""> </span>wrote:<br class="">
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">Hi Everyone,</div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><b class="">In regards to Antranig’s proposal:</b></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">If I’m reading <a href="http://semver.org/#spec-item-9" target="_blank" class="">Semver
spec point 9</a> correctly, using 2.0.0-dev.xxxxxxxxx would
actually be a pre-release of 2.0.0 as opposed to a pre-release of
whatever version comes next. This means that someone following
semver would see these as coming before the 2.0.0 release instead
of after it.</div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">Also, <a href="http://semver.org/#spec-item-10" target="_blank" class="">from point 10</a>, it seems we should have
actually put the release as 2.0.0-dev+xxxxxxxxx regardless of what
approach we take. The “+” indicates that the rest is build meta
data. In our case it’s the date and revision hash. I’ve filed a
JIRA for this ( <a href="https://issues.fluidproject.org/browse/FLUID-6104" target="_blank" class="">https://issues.fluidproject.<wbr class="">org/browse/FLUID-6104</a> )</div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><b class="">In regards to Tony’s proposal:</b> </div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">We currently have a notion of creating a .x branch to
create patch releases from. We currently have <a href="https://github.com/fluid-project/infusion/tree/infusion-1.4.x" target="_blank" class="">1.4.x</a>, <a href="https://github.com/fluid-project/infusion/tree/infusion-1.5.x" target="_blank" class="">1.5.x</a> and <a href="https://github.com/fluid-project/infusion/tree/1.9.x" target="_blank" class="">1.9.x</a>. We could extend this and have a 2.0.x
and 2.x.x lines. I think it would be a lot of work though to be
making commits to 3 branches ( 2.0.x 2.x.x and master ) for one
change.</div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><b class="">My counter proposal:</b></div>
<ul class="">
<li class="">Potentially clean up the erroneous dev builds by
deleting them ( if we can get away with that ), just the ones post
2.0 that were wrong.</li>
<li class="">Increment master based on the commits that are merged.
That is start by changing it to 2.0.1, if a commit is going to have
something that warrants a minor release, create a 2.0.1 patch
release first ( if there were changes ). Then bump the release up
to 2.1.0, and so on.</li>
<li class="">The tricky part comes with a major change, and for
that we’d have to bump the version number up to 3.0.0. We could
either carry on from here as Tony suggested and make a new branch
for 2.x work, or we could just assume everything else will be part
of the next major release. </li>
</ul>
<div class="">I wouldn’t say this is the ideal solution, but it
might be easiest.</div>
<div class=""><br class=""></div>
<div class="">Thanks</div>
<div class=""><span class="m_-5810860281771906670m_-3602002873625389210HOEnZb"><font color="#888888" class="">Justin</font></span></div>
<div class="">
<div class="m_-5810860281771906670m_-3602002873625389210h5">
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div>
<div id="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_sign_1483973257135441920" class="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692bloop_sign">
</div>
<br class="">
<p class="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692airmail_on">
On January 6, 2017 at 7:35:43 AM, Tony Atkins (<a href="mailto:tony@raisingthefloor.org" target="_blank" class="">tony@raisingthefloor.org</a>) wrote:</p>
<blockquote type="cite" class="m_-5810860281771906670m_-3602002873625389210m_-5253666502156343692clean_bq">
<div class="">
<div class="">
<div dir="ltr" class=""><span class="">Hi, All.</span>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I was thinking about this very thing
yesterday.  For the near future, I think Antranig's suggestion
is fine.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">As our community continues to grow, I
would argue that we need to adopt a strategy that better supports
minor and/or patch releases between major releases.  Although
we cannot know whether our next release is major, minor, or a
patch, we do know that there will be another release, and it would
be good for us to discipline ourselves and learn to at least
estimate how big each change we make is.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">My initial thought is that we would
create a branch for the next presumed patch and minor release and
leave master for the next major release.  When submitting new
work, we would start with whichever branch most closely matches the
scope of the change we are making. In choosing a starting branch,
each of us implicitly has to think about and discuss the scope of a
change with others.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">So, for example, we have just release
2.0.0 and have not released any later versions.  We could
create a 2.0.1 branch, and a 2.1.0 branch, each of which has that
version in their package.json.  The version in master would be
updated to 3.0.0.   Bug fixes that are backward compatible
would be submitted against the 2.0.1 branch.  New features
that do not break previous functionality would be submitted against
the 2.1.0 branch.  Breaking changes would be submitted against
master.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">This requires a bit of extra work when
cutting a release.  When we release 2.0.1, we create a 2.0.2
branch.  When we release 2.1.0, we create a 2.2.0 branch and a
2.1.1 branch.  When we release 3.0.0, we create a 3.0.1
branch, and a 3.1.0 branch, and update the master version to
4.0.0.  There are existing tools that manage this for you, we
could also modify the fluid-publish script to take care of much of
this.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">The branch structure would require
some extra work in preparing for a minor or major release, i. e. we
would have to make sure to merge upward, merging changes made to
the 2.0.1 branch that we want to preserve in 2.1, for
example.  This in theory could be largely automatic for patch
and minor releases, but would need to be more of a manual process
for major releases.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">As a simpler alternative, I could see
us adopting this incrementally, by having a 2.1 branch and master,
and at least dividing work according to whether it's appropriate
for a minor or major release.  That would represent less
additional work in managing branches, but would at least get us
started in the important practice of drawing a clear line between
breaking and non-breaking changes in future releases.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Cheers,</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Tony</span></div>
</div>
<div class="gmail_extra"><span class=""><br class=""></span>
<div class="gmail_quote"><span class="">On Thu, Jan 5, 2017 at 8:13
PM, Antranig Basman<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:antranig.basman@colorado.edu" target="_blank" class="">antranig.basman@colora<wbr class="">do.edu</a>></span><span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span>wrote:<br class="">
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
One outcome from our community meeting on 21st Dec 2016 looking
forward to Infusion beyond the 2.0 release was a proposal that we
change our system for numbering dev releases of Infusion. Until now
we have operated a policy that the version number of Infusion in
trunk is derived from the *next* version of Infusion to be released
- for example, our package.json has shown a version of 2.0.0 for
many months, and our "in-code" namespace version has been
fluid_2_0_0.<br class="">
<br class="">
This also implies that all dev releases made to date via the
fluid-publish module have been of the form
2.0.0-dev.xxxxxxxxx<br class="">
<br class="">
The proposal (currently enjoying the status of "silent acceptance"
by virtue of this still being the condition of trunk after the
release) is that we leave all these versions just as they are, and
flip our policy so that the versions shown in trunk will from
henceforth always represent the *previous* release rather than the
upcoming release.<br class="">
<br class="">
The reasons for this are primarily driven by semver
semantics<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="http://semver.org/" rel="noreferrer" target="_blank" class="">http://semver.org/</a><span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span>-
it would seem impossible to anticipate before the fact whether the
upcoming release will be a major, minor, or patch version - this
status could change on the basis of a single commit, and it seems
too much of a burden, as well as highly noisy, to expect that
anyone merging a pull request which in effect changes the status of
the upcoming release to do the work of renumbering all the versions
in trunk.<br class="">
<br class="">
There had been a further driver in the form of a bug in
fluid-publish which has since been fixed in the branch currently in
review -<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="https://github.com/fluid-project/fluid-publish/pull/5" rel="noreferrer" target="_blank" class="">https://github.com/fluid-pro<wbr class="">ject/fluid-publish/pull/5</a><span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span>-
that the "most recently published dev release" would supersede all
previous proper releases. This is no longer relevant since the bug
has been fixed. However, adopting this policy will create the
oddity that pre-2.0 release and post-2.0 (but pre next official)
release dev releases of Infusion will be somewhat indistinguishable
in that they will all have versions of the form 2.0.0-dev.xxxxxxxxx
- however, this is where our dev release numbering policy comes in
handy in that we can still refer to the date field to note that any
of these dated after Dec 6th 2016 (e.g.
2.0.0-dev.20161219T170555Z.577<wbr class="">8f7e) must be
post-2.0 release dev releases.<br class="">
<br class="">
Any comments/suggestions?<br class="">
<br class="">
Cheers,<br class="">
<br class="">
Antranig<br class="">
______________________________<wbr class="">_________________________<br class="">
fluid-work mailing list -<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank" class="">fluid-work@lists.idrc.ocad.c<wbr class="">a</a><br class="">
To unsubscribe, change settings or access archives,<br class="">
see<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" rel="noreferrer" target="_blank" class="">http://lists.idrc.ocad.ca/<wbr class="">mailman/listinfo/fluid-work</a><br class=""></blockquote>
</div>
<br class=""></div>
______________________________<wbr class="">_________________________<br class="">
fluid-work mailing list -<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank" class="">fluid-work@lists.idrc.ocad.c<wbr class="">a</a><br class="">
To unsubscribe, change settings or access archives,<br class="">
see<span class="m_-5810860281771906670m_-3602002873625389210Apple-converted-space"> </span><a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank" class="">http://lists.idrc.ocad.ca/<wbr class="">mailman/listinfo/fluid-work</a></div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">______________________________<wbr class="">_________________________</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">fluid-work mailing list - <a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank" class="">fluid-work@lists.idrc.ocad.ca</a></span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">To unsubscribe, change settings or access
archives,</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">see <a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank" class="">http://lists.idrc.ocad.ca/mail<wbr class="">man/listinfo/fluid-work</a></span></div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
<br class=""></div>


</div></div></span></blockquote></body></html>