Re: [paho-dev] Organizing Paho Releases

[Roger Light <roger@xxxxxxxxxx>]

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