Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Paho Release 0.9 Review Documentation (for review)

For completeness...

An IP Log review is not required for service releases. A service release can, however, contain additional IP or leverage new third party libraries (the sorts of things that might result in a changed IP Log). The only real restriction is that service releases should not contain any new functionality. A service release can contain bug fixes for existing functionality only.

HTH,

Wayne

On 04/23/2014 10:33 AM, David M Williams wrote:
I'll give a couple of answers to make sure I cover all the basis ... but, in general, you're right, what ever is reasonable for your project AND adopters is fine, for service releases. (The key being that only "service field" is changing, and that no changes to IP Log is required).
So, answer 1? Is the question based on exact timing of bugs found/fixed and the release review? If so, you can change exact content of the "release" pretty much any time before the literal review, just keep everyone informed and be explicit if it effects "IP Log". If does not, it is pretty much up to you. If does effect IP log, then you can still tweak that, up to "last minute", but that's more up to Eclipse IP staff if they can accommodate last minute change (this could happen for example, if the fix for that critical bug came from existing committer, or was a patch provided by non-committer. Even then, if its a matter of "adding a name", that's usually fine ... but if its something large, then that's the point it might require some delay so that they can do their usual analysis to make sure it is IP Clean.).

Answer 2: You (obviously?) don't want to do a service release every time you fix any 'ol bug, so its sort of a trade off: if "critical" enough that any/every user/adopter should pick up the fix, then service release would be best, OR if merely important, but not critical, you can sometimes simply provide a "patch" .... and often just attached to a bugzilla is fine ... with a statement that the fix/patch will be included in the next release or service release. Keep in mind, too, that its usually best to "make fix available" as a "service release candidate" for a month or so, and make sure it really fixes the problem for real adopters/users without having some unanticipated side-effect.

From my (little) understanding of your project, I think it's reasonable that a component can have its own "service release" independent of the rest of the larger project, but also remember, its conceptually equivalent, and often easier for adopters/users to understand what to do, if you call or package "the whole project" as a service release, even though, only one component has actually changed. This just makes it easier to communicate things like "use release .91 of Paho" rather than (imagine this over time, several months from now) use .90 of base Paho, plus .91 of this component, plus .92 of this other component, .... etc. That gets confusing quicker than you might imagine.

I hope this brief summary gives you the general guidance you need. I'm sure there is "exceptions to every rule" so don't be afraid to ask, in future, if you think you have an exception to any of the general guidelines, and as long as you communicate well to your users and adopters and make it easy for them to "keep things straight", then I think Eclipse and staff can accommodate just about any thing you need. Make sense?

HTH





From:        Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To:        paho-dev@xxxxxxxxxxx,
Date:        04/23/2014 05:05 AM
Subject:        Re: [paho-dev] Paho Release 0.9 Review Documentation (for review)
Sent by:        paho-dev-bounces@xxxxxxxxxxx




Hi Roger,

good question.  The Eclipse docs say that Service Releases do not need a
review.  For practical reasons, it would be good if we only had to
synchronize all the components on non-service releases.  In fact, I
don't see any other way being reasonable.  We should get some input from
the project mentors on this.

Ian
On 04/22/2014 11:11 PM, Roger Light wrote:
> Hi Ian,
>
> Great, that makes sense.
>
> My final questions (hopefully) - should I upload 0.9 to PyPi now or not?
>
> Do we need to do 0.9.x releases as a project or not? So if I discover
> an important bug in a few weeks and would like to release an update,
> does the Java etc. client have to make a 0.9.1 release as well?
>
> Cheers,
>
> Roger
>
> On Tue, Apr 22, 2014 at 10:01 PM, Ian Craggs
> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Hi Roger,
>>
>> thanks for the info.  I realize that the Python client has support for 3.1.1
>> (so do the Java and C clients in the development streams), I didn't want to
>> put that goal into this release without having all the clients at the same
>> level.  Leaving it for 1.0 in June seemed better.
>>
>> I'll pick and choose some of the other uses and links - I didn't want to
>> overload any particular section, and I want to save some items for next time
>> :-)
>>
>> Iam
>>
>>
>> On 04/22/2014 06:20 PM, Roger Light wrote:
>>> Hi Ian,
>>>
>>> A couple of comments:
>>>
>>> The Python client has support for 3.1.1, although it is less well
>>> tested than 3.1 of course.
>>>
>>> It also indirectly makes use of OpenSSL because that is what Python
>>> uses in the back end. The same comments about the user choosing the
>>> version of OpenSSL applies here.
>>>
>>> There are now 92 resolved and 31 unresolved bugs overall, and 0 listed
>>> bugs for the Python client :)
>>>
>>> I've found some talks and other applications that make use of the Python
>>> client.
>>>
>>>
https://github.com/jpmens/mqttwarn
>>>
>>>
http://jpmens.net/2014/02/17/introducing-mqttwarn-a-pluggable-mqtt-notifier/
>>>
>>>
https://speakerdeck.com/jpmens/mqtt-for-sysadmins
>>>
https://www.youtube.com/watch?v=iIZMHJSU13E
>>>
>>>
>>>
https://ep2013.europython.eu/media/conference/slides/messaging-for-the-internet-of-things.pdf
>>> <- references the Python client back when it was still mosquitto.py.
>>> Don't know if that counts :)
>>>
>>> The owntracks (google latitude replacement based on MQTT) android app
>>> is based on Paho Java.
http://owntracks.org/ Yes, Jan-Piet Mens is
>>> involved with that as well...
>>>
>>> Flukso
https://www.flukso.net/ uses Paho Python:
>>>
https://github.com/wouterh/flukso-mqtt-client
>>>
>>> There are 79 results when you search for "paho" on stackoverflow (I've
>>> just added the 'paho' tag as well, so anybody can tag questions for
>>> paho).
>>>
>>> Cheers,
>>>
>>> Roger
>>>
>>>
>>>
>>> On Tue, Apr 22, 2014 at 5:14 PM, Ian Craggs
>>> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>> All,
>>>>
>>>> I have put together the review information for Paho release 0.9, here:
>>>>
>>>>
https://projects.eclipse.org/projects/technology.paho/releases/0.9.0/review.
>>>>
>>>> Please let me know of any updates or changes you would like to be made.
>>>>
>>>> My aim is to get the review doc approved by the PMC and submitted by COB
>>>> on
>>>> 24th (Thursday).
>>>>
>>>> --
>>>> Ian Craggs
>>>> icraggs@xxxxxxxxxx                 IBM United Kingdom
>>>> Committer on Paho, Mosquitto
>>>>
>>>> _______________________________________________
>>>> paho-dev mailing list
>>>> paho-dev@xxxxxxxxxxx
>>>>
https://dev.eclipse.org/mailman/listinfo/paho-dev
>>> _______________________________________________
>>> paho-dev mailing list
>>> paho-dev@xxxxxxxxxxx
>>>
https://dev.eclipse.org/mailman/listinfo/paho-dev
>>
>> --
>> Ian Craggs
>> icraggs@xxxxxxxxxx                 IBM United Kingdom
>> Committer on Paho, Mosquitto
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/paho-dev
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Committer on Paho, Mosquitto

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon
          France 2014

Back to the top