* enable ui module publication
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* use main changelog of Prometheus to reflect the changes of the packages
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* ignore changelog and license in the libs
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
* replace perses references
Signed-off-by: Augustin Husson <husson.augustin@gmail.com>
Update the release documentation about dependencies.
* We now have dependabot to auto-update things.
* Add note about some manual dependency work.
Signed-off-by: SuperQ <superq@gmail.com>
* Proper support for go modules.
This pull requests makes Prometheus go-mod compatible.
The general idea is to release the Prometheus libraries as v0.x
releases, next to the v2.x tags used by end users.
This is done by mirroring Prometheus 2.x tags with Prometheus 0.x tags.
When v2.X.0 is released, we would release v0.X.0.
Pre-go mod versions are retracted from go.mod. This is not nice but
should work.
Only v2.x tags will be built and released by CI. v0.x.x tags would just
be normal tags in the repo, not promoted as releases.
Signed-off-by: Julien Pivotto <roidelapluie@inuits.eu>
* 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>
