Skip to content

[6.x] [eslint-config-kibana] 0.9.0 and 0.10.0#13318

Merged
cjcenizal merged 2 commits intoelastic:6.xfrom
cjcenizal:backport/13259/6.x
Aug 3, 2017
Merged

[6.x] [eslint-config-kibana] 0.9.0 and 0.10.0#13318
cjcenizal merged 2 commits intoelastic:6.xfrom
cjcenizal:backport/13259/6.x

Conversation

@cjcenizal
Copy link
Copy Markdown
Contributor

Backports #13090 and #13259

CC @weltenwort

@cjcenizal cjcenizal added the backport This PR is a backport of another PR label Aug 3, 2017
@cjcenizal cjcenizal merged commit 0ac9c2f into elastic:6.x Aug 3, 2017
@cjcenizal cjcenizal deleted the backport/13259/6.x branch August 3, 2017 15:49
@weltenwort
Copy link
Copy Markdown
Member

Just out of curiosity, do we need to backport changes to stuff in /packages? There is no useful way to match up the npm versions with the Kibana branches anyway.

@cjcenizal
Copy link
Copy Markdown
Contributor Author

cjcenizal commented Aug 3, 2017

Hmm... the way I'm looking at it is, if I check out a branch, I'd expect that branch to have a logical commit history and a consistent internal state. So, I'd find it a little strange if I know that we store the source for a dependency within the repo, yet that dependency's source is several versions behind the version we depend upon. It can seem like a mistake to someone who's reading the code. For that person to understand what's really going on, they'd need to check out another branch or poke around on GitHub. IMO, we should treat branches as self-contained units, so this kind of external exploration doesn't become necessary to understand the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport This PR is a backport of another PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants