Please release 6.1.0 or at least 6.0.1

[ashvejnov]

Damn, I've forced IT to upgrade from 4.x to 6.0.0 and after couple of days I've realized, that this "early bird" 6.0.0 is super-bugged from UI/UX perspective (as it usually happens to any first version of major update). Later on I saw 6.0.1rc with dozens of fixes, but it wasn't released. Now I see 6.1.0rc, but it seems it's stuck too.

My IT admin is strictly rejecting anything except "official release". His "religion", okay... but in the end I'm really suffering with 6.0.0 and many of my teammates too.

[manimovassagh]

I feel your pain. 6.0.0 was rough around the edges and it's frustrating to be stuck on it when you can see the fixes sitting in RC branches.

A few things that might help while you wait:

1. Pin specific bug-fix commits -- If your IT admin won't run an RC, you can cherry-pick individual fix commits from the 6.0.1rc or master branch into your 6.0.0 deployment. Build from source with just the fixes you need:

   git clone https://github.com/apache/superset.git
   git checkout 6.0.0
   git cherry-pick <commit-hash>  # repeat for each fix
   docker build -t superset-patched .

   This keeps you on an "official" base while addressing the worst issues.

2. Run from the RC tag directly -- The RC images are published to Docker Hub. If your admin's concern is about stability rather than policy, point out that RCs are feature-frozen and only contain bug fixes on top of the last release. apache/superset:6.1.0rc1 is significantly more stable than 6.0.0 for day-to-day use.

3. Track the release timeline -- Release discussions and votes happen on the dev@superset.apache.org mailing list. That's where you'll see the vote threads for 6.0.1 or 6.1.0 GA. Subscribing there gives you a heads-up before the official announcement.

The Apache release process requires a formal vote from committers, which is why RCs can sit for a while. But the fixes are real and tested -- the RC label is more about governance than quality.