* update documentation around react-app and how to upgrade the npm dependencies
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* wording around caution to take when updating the deps
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* fixing the npm version to be used and explain where you should perform the npm install command
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* simplify what is required to build prometheus from the source
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* aligned period and removed redondant word installed
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* set nodeJS version to be used at 16
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* describe manuel steps to update a dependency for the react-app
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* rewording of the manuel step to update the dependencies
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* Makefile.common: add 'update-deps' target
Also updated the RELEASE.md document to adjust the instructions about
dependencies management.
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Rename udpdate-deps -> update-go-deps
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Remove use of jq
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Use $(GO) instead of literal "go"
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
👋
I am happy to do next release. This is because we spent a lot time recent weeks in query optimizations on Prometheus, Thanos, and Cortex, so 2.18 release might have significant changes like:
* Chunk Iterators finally ❤️
* @pstibrany and @pracucci major optimizations to postings
* Potentially https://github.com/prometheus/prometheus/issues/6878 with @mkabischev help.
I know I was a release Shephard just in December, but given that I have full context for those I feel like I can help in releasing 2.18 a lot.
It also includes an update of RELEASE.md since this version simplifies a
bit the release process: promu will take care of drafting the GitHub
release.
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
This codifies how 2.10 was released. It removes the inconsistency of
freezing master for pre-releases but handling post-release bug fixes
in a separate branch.
The previous instructions came from a time where master was often in
bad shape. However, that's a problem of its own, which should be
avoided at all times and not only when a release is imminent. On other
words, freezing master can still happen if it is in bad shape and we
need a break from feature development and just fix the bugs for a
while. However, it should not happen as a formal step during the
release of a release candidate. On the contrary, a release candidate
is not really a release candidate if we already know it is in such a
bad shape that we need bug fixes. On the other hand, if we truly
believe the RC could be identical to the final release, there is no
need to freeze master.
I can explain more of the concept if there is still a need for
clarification.
Signed-off-by: beorn7 <beorn@grafana.com>
I'm willing to do this under the condition that I can run an
experiment with never freezing master. See addition in the file.
I believe, this way is more consistent with how we handle the bugfix
releases after the final minor release is cut. It's at least worth a
try.
Signed-off-by: beorn7 <bjoern@rabenste.in>
