Nah, I think you're totally fine Nate. The list I provided was some
ideas about things that could be done to validate a release. We were asked
for something similar re: the Java driver so I thought it might be useful
for this driver as well.
For the record it was never my intent for that list to be exhaustive.
I'm sure others on this list can come up with even more worthwhile tests. :)
From my perspective any combination of the steps in my earlier message
are good, although I think your combination (validating the tag and
confirming that tests are good) is a pretty good baseline. Running a test
app or two using the new version is probably beneficial (mainly for sorting
out any weirdness re: distribution or install) but doesn't seem as
exhaustive as running the unit tests. I'd say anybody who did one or both
of those had "tested the build" but that might just be me. I went into
detail on the wheel vs. local build in my previous message for those who
are really industrious.
Thanks Nate!
- Bret -
On Thu, Mar 26, 2026 at 7:33 PM Nate McCall <[email protected]> wrote:
> I always check for build and clean tests (figured it's implied at this
> point given previous discussions), should we be doing something more for
> the drivers? I guess im wondering what's implied by "tested the build" for
> drivers? Thanks for posting the extra details either way.
>
> On Fri, Mar 27, 2026 at 11:13 AM Bret McGuire <[email protected]>
> wrote:
>
>> A quick note here explaining some steps that can be taken to test and
>> validate this release. We did something similar
>> <https://lists.apache.org/thread/gpy5spj05dqorxffgrg76qc05rxbcgs5> for
>> the Java driver and it seemed to be useful for folks so I thought I'd try
>> it here as well.
>>
>> I'd recommend doing any of the testing below in a Python virtual
>> environment, especially if you're going to be installing anything; no
>> reason to mess with your global Python install. You can find out more
>> about virtualenvs here <https://virtualenv.pypa.io/en/latest/>. If
>> you're so inclined I'd also recommend looking into uv
>> <https://github.com/astral-sh/uv> to manage both your virtualenvs and
>> local Python installs. Not required by any means; it's perfectly fine to
>> just do something like "python -m venv my_venv". But if you're doing a lot
>> with Python environments uv has some really nice features.
>>
>> In no particular order:
>>
>>
>> - Validate that the release commit hash lines up to the tag
>> referenced above
>> - Locally build a source distribution and confirm that it matches up
>> to what's in SVN
>> - pip install build
>> - python -m build --sdist
>> - Download the source tarball from SVN and run unit tests locally
>> - pip install -r test-requirements.txt
>> - pytest tests/unit
>> - Try running some sample apps against the module currently available
>> on testpypi
>> - Similarly to what's done on the Java side with Nexus you can use
>> testpypi just like you'd normally use pypi
>> - pip install -i https://test.pypi.org/simple/
>> cassandra-driver==3.30.0
>>
>>
>> If you plan on installing cassandra-driver into your environment from
>> testpypi it might be useful to note which platform you're installing on.
>> Python supports the idea of binary builds of packages for specific
>> platforms and Python runtimes... that's what a wheel is. We've built a
>> number of wheels for common platforms for all Python versions supported by
>> this release, so if you do an install with one of those platform/Python
>> combinations you'll get the wheel and not have to build anything at install
>> time. If you use something other than these combinations (say an older
>> version of Python or trying an install on OpenIndiana) pip will try to
>> build it for you locally. Most installs will wind up using the wheels but
>> if somebody has a setup which allows us to test a non-wheel install that
>> would be pretty awesome.
>>
>> Let me know if you have any questions!
>>
>> - Bret -
>>
>>
>> On Thu, Mar 26, 2026 at 4:07 PM Nate McCall <[email protected]> wrote:
>>
>>> +1
>>> (verified commit hash for 3.30.0 tag as 65b26fe4)
>>>
>>> On Wed, Mar 25, 2026 at 12:37 PM Bret McGuire <[email protected]>
>>> wrote:
>>>
>>>> Greetings all! I'm proposing the test build of Cassandra Python
>>>> Driver 3.30.0 for release.
>>>>
>>>> sha1: 65b26fe4a3076870436965a81be5327b759b3e64
>>>> Git:
>>>> https://github.com/apache/cassandra-python-driver/releases/tag/3.30.0
>>>> Source release:
>>>> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-python-driver/3.30.0/
>>>> Changelog:
>>>> https://github.com/apache/cassandra-python-driver/blob/trunk/CHANGELOG.rst#3300
>>>> TestPypi: https://test.pypi.org/project/cassandra-driver/3.30.0/
>>>> (includes wheels for release)
>>>>
>>>> This is the first release of the Python driver since its donation to
>>>> the Apache Software Foundation. We've updated the platform support to
>>>> follow our convention that all Python runtimes that are not EOL at time of
>>>> release are officially supported. For 3.30.0 that works out to CPython
>>>> 3.10 through 3.14, although in reality older Pythons will probably continue
>>>> to work well (we just don't officially support them). In terms of changes,
>>>> we dropped Python 3.9 (supported in 3.29.3) and added Python 3.14.
>>>>
>>>> This release also fixes a few issues with our wheel builds. As part
>>>> of these fixes we've dropped support for Win32 wheels entirely. Win32
>>>> users can still use the driver... they'll just have to build the release at
>>>> install time.
>>>>
>>>> This release also marks our conversion away from setup.py and
>>>> towards pyproject.toml for managing project metadata. In the spirit of
>>>> pyproject.toml we've shifted towards a more declarative configuration model
>>>> and away from settings which can be overridden at runtime. All existing
>>>> configuration options should still be present... they likely just moved
>>>> around a bit.
>>>>
>>>> Finally, this release marks the eventlet, gevent and Twisted event
>>>> loops as deprecated following the previous conversation
>>>> <https://lists.apache.org/thread/49w0wbobzttpnqg05hqlnjpd1tvnd0v9> on
>>>> this list. These event loops will be removed in our next release (again
>>>> following the conclusion of the previous conversation).
>>>>
>>>> The vote will be open for 72 hours (longer if needed) until ~11:30pm
>>>> GMT on 27 March 2026. Everyone who has tested the build is invited to
>>>> vote. Votes by PMC members are considered binding. A vote passes if there
>>>> are at least three binding +1s and no -1's.
>>>>
>>>> Thanks all!
>>>>
>>>> - Bret -
>>>>
>>>>
>>>>
