|Re: [paho-dev] Organizing Paho Releases|
Hi Roger, On 11/04/2014 10:46 PM, Roger Light wrote:
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?
not *must* exactly, but I'd appreciate it if we could follow that policy in as much as makes good sense, in the spirit of having open plans, and for me in managing releases. We can document our intentions on a wiki or other places, but the bugs show up in the plan document, which goes into the release review. I've been trying to follow this principle as much as I can recently. The granularity of the bugs is pretty much up to you - the coarsest one would be: one bug with "these are the features that I plan to add for release foo".
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.
It's not going to be the 14th. The IP log has to be submitted and a release review scheduled. It'll have to be next year now, as I'm on vacation for that month (as you know).
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.
Cool. It doesn't answer the <1.0 question for "immature" components though (I'm not expecting that answer from you!)
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?
It wouldn't be "official" until a project release, but otherwise it could be any time, I guess. Why, would you like the Python client to have another version number?
Cheers, Roger _______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/paho-dev
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Paho Project Lead; Committer on Mosquitto
Back to the top