<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">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">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="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> <br> <div id="bloop_sign_1484587591425889024" class="bloop_sign"></div> <br><p class="airmail_on">On January 13, 2017 at 7:36:53 AM, Justin Obara (<a href="mailto:obara.justin@gmail.com">obara.justin@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap:break-word"><div></div><div>




<title></title>



<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
+1 to Colin and Tony’s latest suggestions.</div>
<br>
<div id="bloop_sign_1484310973663785984" class="bloop_sign"></div>
<br>
<p class="airmail_on">On January 13, 2017 at 5:29:54 AM, Tony
Atkins (<a href="mailto:tony@raisingthefloor.org">tony@raisingthefloor.org</a>)
wrote:</p>
<blockquote type="cite" class="clean_bq">
<div>
<div>
<div dir="ltr"><span>Hi, Colin:</span>
<div><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>Cheers,</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div><span>Tony</span></div>
</div>
<div class="gmail_extra"><span><br></span>
<div class="gmail_quote"><span>On Thu, Jan 12, 2017 at 10:48 PM,
Colin Clark <span dir="ltr"><<a href="mailto:colinbdclark@gmail.com" target="_blank">colinbdclark@gmail.com</a>></span> wrote:<br></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">Hi all,
<div><br></div>
<div>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><br></div>
<div>How about this...?</div>
<div><br></div>
<div>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><br></div>
<div>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><br></div>
<div>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><br></div>
<div>And yes, Tony's point about not deleting releases makes a lot
of sense.</div>
<div><span class="HOEnZb"><font color="#888888"><br></font></span></div>
<div><span class="HOEnZb"><font color="#888888">Colin</font></span></div>
<div>
<div class="h5">
<div><br>
<div>
<blockquote type="cite">
<div>On Jan 11, 2017, at 11:04 AM, Justin Obara <<a href="mailto:obara.justin@gmail.com" target="_blank">obara.justin@gmail.com</a>> wrote:</div>
<br class="m_-3602002873625389210Apple-interchange-newline">
<div>
<div id="m_-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">
I’ve filed a task in JIRA for this work/discussion.</div>
<div id="m_-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">
<a href="https://issues.fluidproject.org/browse/FLUID-6105" target="_blank">https://issues.fluidproject.<wbr>org/browse/FLUID-6105</a></div>
<div id="m_-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">
<br></div>
<div id="m_-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">
Thanks</div>
<div id="m_-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">
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">

<div id="m_-3602002873625389210bloop_sign_1484150654950680064" class="m_-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">

<p class="m_-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">obara.justin@gmail.com</a>) wrote:</p>
<blockquote type="cite" class="m_-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">
<div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><span>Hi
Tony,</span></div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<span><br></span></div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<span>Warning and using the deprecated command sound like a good
approach.</span></div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<span><br></span></div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<span>Thanks</span></div>
<div id="m_-3602002873625389210bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<span>Justin</span></div>
<span><br></span>
<div id="m_-3602002873625389210bloop_sign_1483980996908059136" class="m_-3602002873625389210bloop_sign"></div>
<span><br></span>
<p class="m_-3602002873625389210airmail_on"><span>On January 9,
2017 at 11:41:56 AM, Tony Atkins (<a href="mailto:tony@raisingthefloor.org" target="_blank">tony@raisingthefloor.org</a>) wrote:</span></p>
<blockquote type="cite" class="m_-3602002873625389210clean_bq">
<div>
<div>
<div dir="ltr"><span><span>Hi, Justin:</span></span>
<div><span><br></span></div>
<div><span>I will wait for others to way in further on the
branching strategy, but I wanted to respond to this
point:</span></div>
<div><span><br></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">
<li style="margin-left:15px"><span>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><span><br></span></div>
<div><span>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">npm themselves strongly discourage unpublishing
versions</a> in the documentation for the command used to do
so.</span></div>
<div><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>Cheers,</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div><span>Tony</span></div>
</div>
<div class="gmail_extra"><span><br></span>
<div class="gmail_quote"><span>On Mon, Jan 9, 2017 at 4:13 PM,
Justin Obara<span class="m_-3602002873625389210Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:obara.justin@gmail.com" target="_blank">obara.justin@gmail.com</a>></span><span class="m_-3602002873625389210Apple-converted-space"><wbr> </span>wrote:<br>
</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">
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">Hi
Everyone,</div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><b>In
regards to Antranig’s proposal:</b></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">If
I’m reading <a href="http://semver.org/#spec-item-9" target="_blank">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_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
Also, <a href="http://semver.org/#spec-item-10" target="_blank">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">https://issues.fluidproject.<wbr>org/browse/FLUID-6104</a> )</div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><b>In
regards to Tony’s proposal:</b> </div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">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">1.4.x</a>, <a href="https://github.com/fluid-project/infusion/tree/infusion-1.5.x" target="_blank">1.5.x</a> and <a href="https://github.com/fluid-project/infusion/tree/1.9.x" target="_blank">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_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><b>My
counter proposal:</b></div>
<ul>
<li>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>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>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>I wouldn’t say this is the ideal solution, but it might be
easiest.</div>
<div><br></div>
<div>Thanks</div>
<div><span class="m_-3602002873625389210HOEnZb"><font color="#888888">Justin</font></span></div>
<div>
<div class="m_-3602002873625389210h5">
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
<br></div>
<div id="m_-3602002873625389210m_-5253666502156343692bloop_sign_1483973257135441920" class="m_-3602002873625389210m_-5253666502156343692bloop_sign">
</div>
<br>
<p class="m_-3602002873625389210m_-5253666502156343692airmail_on">
On January 6, 2017 at 7:35:43 AM, Tony Atkins (<a href="mailto:tony@raisingthefloor.org" target="_blank">tony@raisingthefloor.org</a>) wrote:</p>
<blockquote type="cite" class="m_-3602002873625389210m_-5253666502156343692clean_bq">
<div>
<div>
<div dir="ltr"><span>Hi, All.</span>
<div><span><br></span></div>
<div><span>I was thinking about this very thing yesterday. 
For the near future, I think Antranig's suggestion is
fine.</span></div>
<div><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span>Cheers,</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div><span>Tony</span></div>
</div>
<div class="gmail_extra"><span><br></span>
<div class="gmail_quote"><span>On Thu, Jan 5, 2017 at 8:13 PM,
Antranig Basman<span class="m_-3602002873625389210Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:antranig.basman@colorado.edu" target="_blank">antranig.basman@<wbr>colorado.edu</a>></span><span class="m_-3602002873625389210Apple-converted-space"> </span>wrote:<br>
</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>
<br>
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>
<br>
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>
<br>
The reasons for this are primarily driven by semver
semantics<span class="m_-3602002873625389210Apple-converted-space"> </span><a href="http://semver.org/" rel="noreferrer" target="_blank">http://semver.org/</a><span class="m_-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>
<br>
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_-3602002873625389210Apple-converted-space"> </span><a href="https://github.com/fluid-project/fluid-publish/pull/5" rel="noreferrer" target="_blank">https://github.com/fluid-<wbr>project/fluid-publish/pull/5</a><span class="m_-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>8f7e) must be post-2.0 release
dev releases.<br>
<br>
Any comments/suggestions?<br>
<br>
Cheers,<br>
<br>
Antranig<br>
______________________________<wbr>_________________________<br>

fluid-work mailing list -<span class="m_-3602002873625389210Apple-converted-space"> </span><a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank">fluid-work@lists.idrc.ocad.<wbr>ca</a><br>
To unsubscribe, change settings or access archives,<br>
see<span class="m_-3602002873625389210Apple-converted-space"> </span><a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" rel="noreferrer" target="_blank">http://lists.idrc.ocad.ca/<wbr>mailman/listinfo/fluid-work</a><br>
</blockquote>
</div>
<br></div>
______________________________<wbr>_________________________<br>

fluid-work mailing list -<span class="m_-3602002873625389210Apple-converted-space"> </span><a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank">fluid-work@lists.idrc.ocad.<wbr>ca</a><br>
To unsubscribe, change settings or access archives,<br>
see<span class="m_-3602002873625389210Apple-converted-space"> </span><a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank">http://lists.idrc.ocad.ca/<wbr>mailman/listinfo/fluid-work</a></div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br></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">______________________________<wbr>_________________________</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">

<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">
fluid-work mailing list - <a href="mailto:fluid-work@lists.idrc.ocad.ca" target="_blank">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">

<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">
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">

<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">
see <a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank">http://lists.idrc.ocad.ca/<wbr>mailman/listinfo/fluid-work</a></span></div>
</blockquote>
</div>
<br></div>
</div>
</div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
</blockquote>


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