Closed brylie closed 5 years ago
Issue-Label Bot is automatically applying the label #bug
to this issue, with a confidence of 0.79. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
I think there are no stable releases yet due to licensing issues with Apache. See #6785 for further information.
Is the issue still relevant? In case it's not, please consider closing it. Thanks :)
I I now understant more about the underlying reasons for the missing tags.
believe this issue is a broader topic than #6785, and should remain open until the release tags are added.
The ASF told us to not push non-ASF releases to Pypi or as Github tags until we sort out the ASF-compliant release process. I've been working on a release but work is still ongoing. There's a thread or 2 on the dev@ mailing list to follow.
Major work was to sort out licenses and move all 3rd party code out of the source release / Github repo.
@mistercrunch exists any ETA for ASF-compliant release process to be finished?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned
to prevent stale bot from closing the issue.
Ping. This is a maintenance task that should not fall through the cracks.
@brylie - from my use, v0.33.0rc1 is stable; v0.34.0rc1 is not - I just wanted to give you some insight.
@ericandrewmeadows the RC is getting voted on at this moment as the ASF mailing list, commenting on the voting thread would be more helpful. Also opening bugs with a 0.34
label would help us stabilize the release branch.
The reason there's been no releases (and therefore no release tags other than RCs) is related to the complexity of the process imposed by the ASF along with the lack of volunteers to do the work to comply. It mainly consisted of sorting out and cleaning up licenses in our dep tree, as well as automating the process and preventing regression. Also, well the release process is a bit clunky and hard to automate, especially the email crafting and voting part... Some of the steps have been recently documented here: https://github.com/apache/incubator-superset/tree/master/RELEASING
We were told pretty clearly by ASF folks to not release to pypi or any other methods that don't align with the ASF process. Which is reasonable: if we want to be an ASF project, we should comply to the rules of the ASF. While the community and meritocracy in the project has been vocal about being/staying part of the ASF, people haven't been jumping to offer to work in that direction.
It turns out that crafting a clean-licensed ASF-stamped release is not easy, and it's not super sexy work, so that's why it's taking time.
Luckily the project is super healthy in all metrics other than releases, and well I just kicked off a vote on general@incubator, so watch for the mailing list for a release, hopefully soon.
Perhaps we could create a program to offset Whim users' carbon footprint, e.g. by contributing to sustainability projects via a registered charity. That way we could send a message that we are working to make transportation carbon neutral.
I hope that doesn't preclude Superset from releasing an official Docker image, as that has turned out to be the biggest blocker for our company to even evaluate Superset against other projects like Tableau Server, Redash, Metabase, and Grafana.
@brylie amancevice/superset
has started maintaining non-pypi and edge
builds. Plenty of ASF projects have official images, so it is not precluded and will likely happen, IMO
0.34.0
is out, now we need to figure out "convenience releases" (pypi / docker/ . ...)
Some instructions to build the source release, with a reference docker file to build from source https://github.com/apache/incubator-superset/tree/master/RELEASING
[From my understanding,] While releasing binaries (anything that would have our minified JS bundles) in the name of the ASF forces us to have a LICENSE file detailing everything that's in that release (700+ libs in the dep tree) and may be tricky to maintain, we can easily share reference dockerfiles (as opposed to images that contain the minified bundles).
The Dockerfile provided in RELEASING/
are not optimized in any way for either build times, image size, or flexibility, but could be modified to take this into account. From my experience it can be difficult to achieve these optimizations and provide something that suits everyone.
@mistercrunch oh jeez, you mean like airflow's licenses
dir?
Maybe that number can be cut down by analyzing webpack treeshaking results to see exactly which libraries are bundled. There are also some license crawling tools on npm... sounds like a substantial logistical burden regardless
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned
to prevent stale bot from closing the issue.
There are several missing release tags since 0.28.0. It seems that rc versions are getting tagged, but stable release tags are missing. This makes it difficult to ascertain the frequency of stable releases.