* create lezer-promql module + move codemirror to a pure esm module + unified dependencies
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* ignore test utils file and remove the type "module" in package.json
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* use jest to run the lezer-promql test
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* give an automatic way to update the ui dependencies
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* update all dependencies using make update-npm-deps
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* fix react-app test
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* remove generated file
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* remove unnecessary backslash in script
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* fix reviews
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* rewording
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* use npx to run lezer-generator
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
This adds the following:
- Find a new volunteer for the release shepherd if needed.
- Consider experimental features for promotion/demotion.
The latter could need more detailed explanation, but I guess we can
add those once we have the planned metrics for feature flags. For now,
I just wanted to have that point in so that it is not completely
forgotten.
Signed-off-by: beorn7 <beorn@grafana.com>
Co-authored-by: Levi Harrison <git@leviharrison.dev>
In a meeting at Grafana Labs, we had the shocking revelation that the
next release is scheduled to happen soon, but there is no release
shepherd for it yet.
(Which reminds me: Perhaps we should make it a responsibility of the
release shepherd to make sure there is one for the next release, too?)
Given my current part-time commitment, I would actually try to avoid
being the release shepherd, but on the other hand, it's about time
that a Grafanista to do the job again, and the only one who could do
it at all in the room was me. @csmarchbanks volunteered for the next
release. So here we are.
Of course, if any other team member would like to jump in and do this
release or the next, we'll happily insert you into the list.
Signed-off-by: beorn7 <beorn@grafana.com>
* 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>
