Closed hdgarrood closed 4 years ago
If we are going to make this change in every core library, do you think it would be worth making an issue in every core library?
do you think it would be worth making an issue in every core library?
As in, an issue to restore the configuration to the original one so we don't forget to do that?
Yeah, although I'm not sure we need one. My thinking is that this is going to be an issue for every core library (if we want to be able to use CI while we're updating things for v0.14.0), and we'll need to go back over all of the core libraries anyway once we've released v0.14.0 to cut proper releases and put proper version bounds in their bower.json files, so we could restore the CI configurations then too, and I'm not sure we need an issue to remind us.
If we will already have to back over them for other reasons then let’s skip the issue. It would be useful to have a checklist of updates to make, though, because it’s easy to forget little things like updating the CI file when you’re updating a lot of libraries. Not sure where that should live but I think it would help us catch everything.
I'd like to keep CI working while we're preparing the core libraries for the upcoming 0.14.0 release. This seems like a reasonable way of doing it for now. We'll need to go back through the core libraries to tag proper versions again later anyway, so we can revert this change then.
As an alternative I considered making a
v0.14.0-rc2
release on npm, but unfortunately the npm installer isn't happy with that:This would probably be relatively easy to fix, but a one-line change in .travis.yml seems easier.