You can’t skip the release vote process but you can make the vote a lot easier / cleaner if the only diff / commit is the one line change.
We can a quick role in dev@ and once there is 3 votes (like today) we bring it to IPMC for 72hr. Hopefully it’s not too bad. Unfortunately you will need to publish the Java artifacts though because they go together in the same repo. In some projects they have several repo that makes it easier to change one codebase vs another. In this specific case you can also fix this in https://github.com/apache/incubator-sedona/blob/master/python/setup.py and just tell people to install with pip from there (git repo), to workaround. Python people are generally very flexible so I don’t personally think this issue is a major problem. On Tue, May 25, 2021 at 10:35 PM Jia Yu <ji...@apache.org> wrote: > And, this post-release will not change any Sedona Python source code. The > only place we need to change is the Spark version in "setup.py" which is > used for publishing the Python package. > > On Tue, May 25, 2021 at 10:30 PM Jia Yu <ji...@apache.org> wrote: > >> Hi Felix (CCed Pawel), >> >> A user immediately reported an issue in Sedona Python 1.0.1. The Python >> release was misconfigured to only allow PySpark < 3.1.0 [1] >> >> This will automatically uninstall PySpark 3.1.1 and re-install PySpark >> 3.0.2 on the user's local machine. While the user could re-install PySpark >> 3.1.1 back afterward, this behavior is kind of not good. >> >> I wonder if we can release Sedona 1.0.1 post-release on PyPi without >> going through the voting process [2]. E.g., 1.0.1-post1. The post-release >> "post1" probably will not even appear on Pypi.org. >> >> [1] >> https://github.com/apache/incubator-sedona/blob/master/python/setup.py#L39 >> [2] https://www.python.org/dev/peps/pep-0440/#post-releases >> >> Thanks, >> Jia >> >
