[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Organizing Paho Releases
|
Hi Ian,
> are your feature changes for 1.1 in the Python client described in bugs so
> that they show up on this page?
>
> https://projects.eclipse.org/projects/technology.paho/releases/1.1.0/bugs
>
> if not... then they should be.
They are, although there are some bugs there that have already been
fixed in service releases.
Just to be clear, are you saying that if I decide to implement a
feature I must file a bug for it first?
> When would be a good time for the 1.1 changes that you want to put into the
> Python client? That is, a good time for a 1.1 release?
There are only one or two bugs that need fixing for Python 1.1, so not
that long. If you said the release was on the 14th, I'd cope.
> I had advice previously that the version numbers for each component didn't
> need to match Paho as a whole. It was manageable for the first release, but
> as we get more components, I don't see how it would be. After all, a
> completely new component, like the embedded clients for instance, when that
> is released I would probably go for a 0.8 and 0.9 before going to a 1.0.
> When a component reaches 1.0, the API is then supposed to not have backward
> incompatible changes, unless the major version number is changed i.e. to
> 2.0. I don't see any other way around this.
Great, if we've had that advice from above then that's great.
> If this means you would like to change the version number on the Python
> client, then you can do.
Ok... but presumably that needs to happen within the context of a
project release?
Cheers,
Roger