Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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