Re: [paho-dev] Organizing Paho Releases

[Roger Light <roger@xxxxxxxxxx>]

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