I agree with everything that you said.
However by 'source release', I was merely referring to a Python/PyPI
packaging technicality, where we distribute the package in the form that is
generated by *python setup.py sdist*,
as opposed to the pre-built binary egg or wheel formats.
But since you brou
Yup, let's just draw a number (whatever we'd like, as long as it follows
the standard PEP for versioning). When we release it, we can advertise
whatever level of stability we expect it to have (i.e. "This is an
alpha, you can try it if you want").
ASF is very strict when it comes to releases i
The Beam guide looks interesting, we could certainly borrow from it.
I'm fine with your suggested process. Here's my interpretation of it:
- No dev releases on PyPI
- Decoupling PhoenixDB versioning from PQS versioning
- Making a proper minor/patch release when important features/fixes l
ASF releases do not have to be on the order of years. As long as we have
three people to vote, we can do releases as often as we'd like. The
lower-bound on release cadence is probably on the order of "weeks" (as
opposed to days) but that's primarily limited by bandwidth of our
volunteers :)
A
One more thing :)
Apache Beam appears to have an excellent release guide which includes
their process which involves PyPi --
https://beam.apache.org/contribute/release-guide/
Maybe we can copy them?
On 6/15/20 1:08 PM, Josh Elser wrote:
Did a little searching..
* Found a 2011 blog post fro
TestPyPi certainly seems useful to practice the release process, and avoid
mistakes with it.
However, I don't think that it is a substitute for a .devN release, which
(in my mind) is meant to give the users something to use until we get all
our ducks in a row to do a proper 1.0 release. The primar
Did a little searching..
* Found a 2011 blog post from sqlalchemy which said (as a project) they
would not post devN releases to pypi
* There's a TestPyPi [1] instead which seems to be for staging work.
Could we play with staging there? And then push to pypi (real) after we
do a normal vote?
Hey Istvan,
Great of you to drive this work!
I do have one concern about pushing the dev releases to PyPi (I'm
assuming that's what you mean). I understand that in the Python world a
"dev" release indicates that this isn't an "official" release [1].
At the ASF, you're correct that we, develo
Hi!
Even though we have adopted the PhoenixDB driver in 2018, there hasn't been
much activity on it, and the version available on PyPI is still the old 0.7
release by Lukas.
Recently I have worked on it quite a bit, adding fixes and new features,
and adopting the partial SQLAlchemy driver from py
