Re: [paho-dev] Paho Release 0.9 Review Documentation (for review)

[David M Williams <david_williams@xxxxxxxxxx>]

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