[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] Organizing Paho Releases
|
Hi Roger,
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.
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?
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.
If this means you would like to change the version number on the Python
client, then you can do.
Ian
On 11/04/2014 05:27 PM, Roger Light wrote:
Hi Ian,
Yes, I've done 1.0.x releases for the Python client as well. My
understanding is the same as yours!
1.1 - ok, that's fine with me. I don't intend to have any major
changes for 1.1, but feature changes definitely.
The "no major updates for the Java..." part is the core point here for
me. Either we version the project as a whole, in which case everything
should have the same version number which increases no matter whether
there were feature changes or not, or each component has its own
version number separate to the project and can decide whether to take
part in a "Paho release train" or
Cheers,
Roger
On Tue, Nov 4, 2014 at 5:09 PM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Roger,
1) you can have a service release for a component at any time, without a
review. So if you just have fixes, you can create a 1.0.1 for example,
separately, when you want. I've done this for the C client. At least,
that's my interpretation, until someone tells me something different :-)
2) the date for the 1.1 release is still tentative. I put it there because
that date was just before I leave for NZ for a month. Looks like it should
be now 1Q 2015 (IP Log reviews need longer). However we need to be sure
what is going into a release before making it happen. If there were no
major updates for the Python client, apart from fixes, then calling it 1.1
doesn't make so much sense. I wasn't planning any major updates for the
Java, C or JavaScript clients either - that is planned for 1.2.
Ian
On 11/04/2014 04:55 PM, Roger Light wrote:
Hi Ian,
This is a tricky problem! Before writing anything else, I see that our
release plan suggests 1.1 will be released in 10 short days. Are we
still planning on doing that? If so, I've got some fixes to sort out
for the Python client :)
I feel as though keeping the version numbers of the different
components the same is going to result in reduced pain down the line.
I also believe that code that joins the Paho project should be treated
as "new", which doesn't conflict with keeping version numbers
consistent across the project.
I'm not sure about the best plan for sub 1.0 components - it seems as
though a permanent incubator project would be the best bet if only it
could have releases.
Cheers,
Roger
On Tue, Nov 4, 2014 at 10:58 AM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello, anyone with suggestions or thoughts!
Paho is a bit different from your average project, being a collection of
disparate components at somewhat different stages of maturity. I am
trying
to decide how to organize official releases of Paho. The next ones would
be
1.1 and 1.2.
1) I would like to release the Android service, but preferably not at 1.0
level, but at 0.8 or 0.9, as I would like to get more feedback from real
use
before deciding it is 1.0 worthy. But the main Paho project has
graduated,
so it doesn't seem right to add it to a Paho release 1.1 for instance.
The
Paho permanent incubator could be the place for it, except that permanent
incubators can't have releases. Another sub-project could solve the
problem
but would be a significant amount of work setting it up. Other
components
will be in the same position in the future.
2) I would like to have an official release which includes Paolo
Patierno's
.Net (and WinRT!) MQTT client, which is currently on version 3.6. I
think
having this version (3.6) in a release 1.1 of Paho, is not a problem,
from
previous discussions. Is there any reason to not go with Paolo's current
versioning?
Thanks
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
