Re: Infusion dev numbering proposal

[Justin Obara]

Hey Colin,

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.

Thanks
Justin

On January 18, 2017 at 11:50:01 AM, Colin Clark (colinbdcl...@gmail.com)
wrote:

Hi all,

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?

If that's the case, we won't have to worry about synchronizing releases
between two separate modules because they will be, well, separate. :)

In other words, this shouldn't exist:

https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L7

It need only be here:

https://github.com/fluid-project/infusion/blob/master/.eslintrc.json#L4

I think maybe this was your original suggestion, am I right Justin?

Colin

On Jan 17, 2017, at 4:28 AM, Tony Atkins  wrote:

Hi, Justin.

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.

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.

Cheers,


Tony

On Mon, Jan 16, 2017 at 6:28 PM, Justin Obara 
wrote:

> 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 fluid_2_0_0
> .
> 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.
>
> Thanks
> Justin
>
>
> On January 13, 2017 at 7:36:53 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> +1 to Colin and Tony’s latest suggestions.
>
>
> On January 13, 2017 at 5:29:54 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Hi, Colin:
>
> 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.
>
> Cheers,
>
>
> Tony
>
> On Thu, Jan 12, 2017 at 10:48 PM, Colin Clark 
> wrote:
>
>> Hi all,
>>
>> 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.
>>
>> How about this...?
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> And yes, Tony's point about not deleting 

Re: Infusion dev numbering proposal

[Colin Clark]

Hi all,

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?

If that's the case, we won't have to worry about synchronizing releases between 
two separate modules because they will be, well, separate. :)

In other words, this shouldn't exist:

https://github.com/fluid-project/eslint-config-fluid/blob/master/.eslintrc.json#L7

It need only be here:

https://github.com/fluid-project/infusion/blob/master/.eslintrc.json#L4

I think maybe this was your original suggestion, am I right Justin?

Colin

> On Jan 17, 2017, at 4:28 AM, Tony Atkins  wrote:
> 
> Hi, Justin.
> 
> 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.
> 
> 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.
> 
> Cheers,
> 
> 
> Tony
> 
> On Mon, Jan 16, 2017 at 6:28 PM, Justin Obara  > wrote:
> 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 fluid_2_0_0 
> .
>  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.
> 
> Thanks
> Justin
> 
> 
> On January 13, 2017 at 7:36:53 AM, Justin Obara (obara.jus...@gmail.com 
> ) wrote:
> 
>> +1 to Colin and Tony’s latest suggestions.
>> 
>> 
>> On January 13, 2017 at 5:29:54 AM, Tony Atkins (t...@raisingthefloor.org 
>> ) wrote:
>> 
>>> Hi, Colin:
>>> 
>>> 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.
>>> 
>>> Cheers,
>>> 
>>> 
>>> Tony
>>> 
>>> On Thu, Jan 12, 2017 at 10:48 PM, Colin Clark >> > wrote:
>>> Hi all,
>>> 
>>> 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.
>>> 
>>> How about this...?
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> And yes, Tony's point about not deleting releases makes a lot of sense.
>>> 
>>> Colin
>>> 
 On Jan 11, 2017, at 11:04 AM, Justin Obara 

Re: Infusion dev numbering proposal

[Justin Obara]

Regarding the earlier conversation regarding the version number in Infusion
master, I believe that discussion has come to a close. I’ve filed a PR to
update the version number to 3.0.0 (
https://github.com/fluid-project/infusion/pull/800 ).

Thanks
Justin

On January 17, 2017 at 8:55:10 AM, Justin Obara (obara.jus...@gmail.com)
wrote:

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.

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.
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Infusion dev numbering proposal

[Justin Obara]

Hi Tony,

Thanks for the feedback. To add on to your proposal a bit, I think we
should consider adding a global for “fluid” still, in addition to the
versioned fluid (e.g. fluid_2_0_0). The reason being that projects making
use of Infusion will likely use the plain fluid namespace as opposed to the
versioned one. Infusion itself uses the versioned namespace, and web
projects wishing to support multiple versions of infusion. However, I’m not
sure if our Node approach would support running multiple versions of
infusion because we dedupe infusion.

Thanks
Justin


On January 17, 2017 at 4:29:03 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, Justin.

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.

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.

Cheers,


Tony

On Mon, Jan 16, 2017 at 6:28 PM, Justin Obara 
wrote:

> 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 fluid_2_0_0
> .
> 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.
>
> Thanks
> Justin
>
>
> On January 13, 2017 at 7:36:53 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> +1 to Colin and Tony’s latest suggestions.
>
>
> On January 13, 2017 at 5:29:54 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Hi, Colin:
>
> 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.
>
> Cheers,
>
>
> Tony
>
> On Thu, Jan 12, 2017 at 10:48 PM, Colin Clark 
> wrote:
>
>> Hi all,
>>
>> 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.
>>
>> How about this...?
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> And yes, Tony's point about not deleting releases makes a lot of sense.
>>
>> Colin
>>
>> On Jan 11, 2017, at 11:04 AM, Justin Obara 
>> wrote:
>>
>> I’ve filed a task in JIRA for this work/discussion.
>> https://issues.fluidproject.org/browse/FLUID-6105
>>
>> Thanks
>> Justin
>>
>>
>> On January 9, 2017 at 11:57:48 AM, Justin Obara (obara.jus...@gmail.com)
>> wrote:
>>
>> Hi Tony,
>>
>> Warning and using the deprecated command sound like a good approach.
>>
>> Thanks
>> Justin
>>
>>
>> On January 9, 2017 at 11:41:56 AM, Tony Atkins (t...@raisingthefloor.org)
>> wrote:
>>
>> Hi, Justin:
>>
>> I will wait for others to way in further on the branching strategy, but I
>> wanted to respond to this point:
>>
>>
>>>- Potentially clean up the erroneous dev builds by deleting them (

Re: Infusion dev numbering proposal

[Justin Obara]

I’ve filed a task in JIRA for this work/discussion.
https://issues.fluidproject.org/browse/FLUID-6105

Thanks
Justin


On January 9, 2017 at 11:57:48 AM, Justin Obara (obara.jus...@gmail.com)
wrote:

Hi Tony,

Warning and using the deprecated command sound like a good approach.

Thanks
Justin


On January 9, 2017 at 11:41:56 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, Justin:

I will wait for others to way in further on the branching strategy, but I
wanted to respond to this point:


>- 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.
>
>
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 npm themselves strongly discourage unpublishing
versions  in the documentation for
the command used to do so.

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

Cheers,


Tony

On Mon, Jan 9, 2017 at 4:13 PM, Justin Obara  wrote:

> Hi Everyone,
>
> *In regards to Antranig’s proposal:*
>
> If I’m reading Semver spec point 9  correctly,
> using 2.0.0-dev.x 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.
>
> Also, from point 10 , it seems we should
> have actually put the release as 2.0.0-dev+x 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 (
> https://issues.fluidproject.org/browse/FLUID-6104 )
>
> *In regards to Tony’s proposal:*
>
> We currently have a notion of creating a .x branch to create patch
> releases from. We currently have 1.4.x
> , 1.5.x
>  and 1.9.x
> . 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.
>
> *My counter proposal:*
>
>- 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.
>- 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.
>- 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.
>
> I wouldn’t say this is the ideal solution, but it might be easiest.
>
> Thanks
> Justin
>
>
>
> On January 6, 2017 at 7:35:43 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Hi, All.
>
> I was thinking about this very thing yesterday.  For the near future, I
> think Antranig's suggestion is fine.
>
> 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.
>
> 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.
>
> 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 

Re: Infusion dev numbering proposal

[Tony Atkins]

Hi, Justin:

I will wait for others to way in further on the branching strategy, but I
wanted to respond to this point:


>- 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.
>
>
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 npm themselves strongly discourage unpublishing
versions  in the documentation for
the command used to do so.

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

Cheers,


Tony

On Mon, Jan 9, 2017 at 4:13 PM, Justin Obara  wrote:

> Hi Everyone,
>
> *In regards to Antranig’s proposal:*
>
> If I’m reading Semver spec point 9  correctly,
> using 2.0.0-dev.x 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.
>
> Also, from point 10 , it seems we should
> have actually put the release as 2.0.0-dev+x 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 (
> https://issues.fluidproject.org/browse/FLUID-6104 )
>
> *In regards to Tony’s proposal:*
>
> We currently have a notion of creating a .x branch to create patch
> releases from. We currently have 1.4.x
> , 1.5.x
>  and 1.9.x
> . 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.
>
> *My counter proposal:*
>
>- 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.
>- 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.
>- 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.
>
> I wouldn’t say this is the ideal solution, but it might be easiest.
>
> Thanks
> Justin
>
>
>
> On January 6, 2017 at 7:35:43 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Hi, All.
>
> I was thinking about this very thing yesterday.  For the near future, I
> think Antranig's suggestion is fine.
>
> 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.
>
> 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.
>
> 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.
>
> This requires a bit of extra work when cutting a release.  

Re: Infusion dev numbering proposal

[Justin Obara]

Hi Everyone,

*In regards to Antranig’s proposal:*

If I’m reading Semver spec point 9  correctly,
using 2.0.0-dev.x 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.

Also, from point 10 , it seems we should
have actually put the release as 2.0.0-dev+x 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 (
https://issues.fluidproject.org/browse/FLUID-6104 )

*In regards to Tony’s proposal:*

We currently have a notion of creating a .x branch to create patch releases
from. We currently have 1.4.x
, 1.5.x
 and 1.9.x
. 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.

*My counter proposal:*

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

I wouldn’t say this is the ideal solution, but it might be easiest.

Thanks
Justin



On January 6, 2017 at 7:35:43 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, All.

I was thinking about this very thing yesterday.  For the near future, I
think Antranig's suggestion is fine.

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.

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.

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.

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.

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.

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.

Cheers,


Tony

On Thu, Jan 5, 2017 at 8:13 PM, Antranig Basman <
antranig.bas...@colorado.edu> wrote:

> 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