Agree that with the workaround for specifying specific versions, pinning
exact versions becomes less useful. +1 for trusting semantic versioning and
allowing dependencies to be updated till next major version whenever
possible. If we run into issues we can ask users to pin specific versions
when
Yeah, I guess that's the difference between releasing source vs running
your own service.
On Fri, Dec 15, 2017 at 2:58 PM Ahmet Altay wrote:
> I agree with Robert. Also there is usually a workaround to unbrake
> previous version by installing a specific version of an offending
I agree with Robert. Also there is usually a workaround to unbrake previous
version by installing a specific version of an offending dependency.
On Fri, Dec 15, 2017 at 2:53 PM, Robert Bradshaw
wrote:
> This has the downside of pinning the dependencies for all downstream
>
This has the downside of pinning the dependencies for all downstream
projects, making it impossible for them to use different versions than
the ones we happened to choose. (Imagine the pain of two or more of
our dependencies pinned all their dependencies...)
On Fri, Dec 15, 2017 at 2:48 PM, Udi
On Fri, Dec 15, 2017 at 2:42 PM, Chamikara Jayalath
wrote:
> +1 for automating the process of checking for possible version bumps.
>
> Also, what do you think about pinning dependencies to exact versions
> (instead of ranges) after cutting a release branch ? This should
+1 for automating the process of checking for possible version bumps.
Also, what do you think about pinning dependencies to exact versions
(instead of ranges) after cutting a release branch ? This should improve
the stability of released SDKs (but not a prefect solution since transitive
On Fri, Dec 15, 2017 at 1:51 PM, Ahmet Altay wrote:
>
> On Fri, Dec 15, 2017 at 1:38 PM, Robert Bradshaw
> wrote:
>>
>> I am also in favor of pinning as an immediate fix, bumping the bound
>> otherwise.
>>
>> Regarding putting an upper bound to avoid being
On Fri, Dec 15, 2017 at 1:38 PM, Robert Bradshaw
wrote:
> I am also in favor of pinning as an immediate fix, bumping the bound
> otherwise.
>
> Regarding putting an upper bound to avoid being broken, the last two
> breaks have been due to just having an (unneeded) upper
I am also in favor of pinning as an immediate fix, bumping the bound otherwise.
Regarding putting an upper bound to avoid being broken, the last two
breaks have been due to just having an (unneeded) upper bound (which
held us back to broken/incompatible releases in relationship to other