Re: Infusion dev numbering proposal

It seemed like we were happy with the latest proposal to have a global for “fluid” and that version specific globals should be defined within the repos that use them. I’ve filed a FLUID-6118 and submitted a PR

Re: Infusion dev numbering proposal

That makes sense to me, yes! Those projects that don't use Infusion but are using eslint-config-fluid are probably pretty scarce, anyway. ;) Colin > On Jan 18, 2017, at 12:11 PM, Justin Obara wrote: > > That’s similar to my original suggestion. I was saying we just have a global > for “fluid”

Re: Infusion dev numbering proposal

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 c

Re: Infusion dev numbering proposal

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 flui

Re: Infusion dev numbering proposal

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

Re: Infusion dev numbering proposal

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

Re: Infusion dev numbering proposal

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 sho

Re: Infusion dev numbering proposal

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 i

Re: Infusion dev numbering proposal

+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

Re: Infusion dev numbering proposal

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, 20

Re: Infusion dev numbering proposal

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 t

Re: Infusion dev numbering proposal

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

Re: Infusion dev numbering proposal

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:

Re: Infusion dev numbering proposal

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

Re: Infusion dev numbering proposal

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

Re: Infusion dev numbering proposal

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 kno