-
Notifications
You must be signed in to change notification settings - Fork 71
More frequent releases #167
Comments
@TotalKrill Thanks for bringing these up. I agree with all your points. Infrequent releases to crates is due to time crunch here at Ather. You might've noticed that there aren't many people working on this crate.
Yeah this is a mess. I'll follow git flow or something similar starting next release. I'm hopeful that all of this will be sorted out starting mid October as I've decided to work full time on this and creating mqtt ecosystem (including embeddable broker and a lightweight core) in rust. But I also need some support. Managing all of this alone is very tough. I'll see if I could find a couple of people who've invested in rust and mqtt and see if a collaboration is possible. Please let me know if you are interested |
Yeah I totally understand the time issue, I am experiencing this as well. I cant wait for the next release of this, even though it might mean a lot of rewrite. I do not know if I can contribute very much though, but I am interested, I could maybe help review and test patches when time allows. |
I'll do what I can to help. I'm slowly starting to understand this codebase and beginning to realize the challenges it faces. |
@tekjar After some thought, I can probably help some when time allows. My main focus would be to get a new release up on crates.io and branch that away to allow for bugfixes on that branch, just getting it a bit more usable in most cases. Do you have any idea on how to start accepting new contributors? |
This software is currently the best mqtt library for rust in my opinion. That being said I would like if we could approach a v1.0.0 soon so that instead of a major refactor when a bug is found there could be just pure bugfix releases happening on v1.0.x branch and v2.0.0 could be the branch where new development is happening.
I am bringing this up because I have a local version that is now a bit behind the version published here that fixed a bug I was having at that time. And the version on crates.io is very much behind and functions differently from what is in this github repo. This has however not really been noticed in the version number 0.30.1
Basically the github repo has one version that is very different in functionality from the one on cargo. And I now have my own branch and github repo I use and I feel that there is really no use in contributing bugfixes here since it will not be published as a bugfix anyway. Which is unfortunate, but if instead of doing all development on "master" doing it on a branch with the next planned release number might be better, leaving a branch for 0.30 that can be used for creating 0.30.x releases that just fixes bugs.
does this sound feasible to you?
The text was updated successfully, but these errors were encountered: