It's still progressing, most work I want for a 2.0 is submitted
(as PR or merged to master). There is small work remaining on the
last PR (update README & example).
I'll be busy this week, but I think the release candidate will be
done next week-end.
This 2.0 will include breaking change (in addition to dropping
support for older Python), but I'm made a migration.md and it
could be as simple as adding a parameter to Client(), see
https://github.com/eclipse/paho.mqtt.python/pull/802 if you want
the details.
The only last work I want to complete before the 2.0 is a pass on
README and publish somewhere the pydoc, but I'll do this between
the RC and the final release.
Pierre Fersing
Le 03/01/2024 à 19:20, Nic Schrading a
écrit :
Woohoo thank you for the update!
On Wed, Jan 3, 2024, 12:22 AM
Pierre Fersing via paho-dev <paho-dev@xxxxxxxxxxx>
wrote:
Hello,
yes I've made progress but not yet the release:
* most PRs are merged
* I'm going to do a 2.0 release due to few breaking
change. I also think to do a release candidate to allow
wider testing before the actual release.
I still want to do a quick pass on issues to include fix
for any issue that should be fixed in this release. I
especially think to issue that require a breaking change.
I expect a release candidate on next week but this
depends on amount of work for the issues review (and their
possible fixes).
Thank you for the update. I'm still
looking forward to the new release. If it's not too
difficult I'd also request that the release support
some of the newer versions of python as well (3.11,
3.12)?
-- Nic
On Wed, Nov 15,
2023, 7:46 AM Pierre Fersing via paho-dev <paho-dev@xxxxxxxxxxx>
wrote:
Hi all,
I didn't forget about the objective of a
release by end of summer... weather is still
beautiful here in south of France, it's still
summer ? :)
More seriously, I've underestimated the time
required by some other personal projet but I
hope to have more free time by end of November
/ early December. I'm rather confident to be
able to do something for this year.
Pierre
Le 27/06/2023 à 16:08, Pierre Fersing a
écrit :
Hi all,
I'm one of the committer on this
repository. I'm short on time to monitor PRs
and issues (hence the high number of issues
:( ). But I still watch the mailing list, so
if you have any serious issues or a PR that
needs some attention, I'll find some time
for them.
If you want to help supporting this
project, you're more than welcome.
I'll try to find a some time this summer to
make a release, it helps showing that this
project is not dead.
Regards,
Pierre
Le 27/06/2023 à 15:32, Philip Couling a
écrit :
Thanks Greg
>Are there serious open issues?
Does it fail to work with Python 3.11?
> Something can be maintained in a
sense while not having changes, if
> there is no reason to have
changes.
What's concerning is that there's 224 open
issues on Github and 26 PRs; on
the face of it there's plenty of
reasons for changes, a few of them
would be useful for me. It seems a
mighty long time for some of these to
remain open with no response, not even
to reject and close them. I really
appreciate that open source projects
are often maintained in people's spare
time, I don't wish to seem ungrateful.
On the contrary, I was really
wondering about the chance of my own
PR(s) being accepted if I submit. A
couple of week's worth of evenings
would be a big waste to spend on a PR
if nobody's monitoring the queue.
On
Tue, 27 Jun 2023 at 13:57, Greg Troxel
<gdt@xxxxxxxxxx>
wrote:
> Is paho.mqtt.python being
actively maintained. The last release
was October
> 2021 and I can only see a single
commit in the repo after that release
on
> github (https://github.com/eclipse/paho.mqtt.python).
>
> I might like to help support this
code base. Though I'm not sure if any
PRs
> I offer will get ignored through
lack of maintenance.
For context, I maintain the pkgsrc
package for this, and use it.
Are there serious open issues? Does
it fail to work with Python 3.11?
Something can be maintained in a sense
while not having changes, if
there is no reason to have changes.
I can't speak for whoever has write
access on the repo, but it seems
obvious that if you have fixed
something, that submitting a PR is
better
than not submitting a PR.