“service-base” module has also APIs like DeviceManagementService and I think such classes should be subjected to semantic versioning.
The idea of splitting up “service-base” module to clearly define what is public and what not sounds good. IMHO it is also easier to maintain in the future.
+1
Karthees
Mit freundlichen Grüßen / Best regards
Kartheeswaran Kalidass
Bosch IoT Hub - Product Area IoT Platform (IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY |
www.bosch.io
Tel. +49 711 811-58717 |
Kartheeswaran.Kalidass@xxxxxxxxxxxx
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jens Reimann
Sent: Dienstag, 28. Januar 2020 10:44
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Definition of Hono's public API
Yes, I agree that the service-base mobile is a rather large chunk of code.
Personally I think it would make sense breaking it up into smaller pieces. Which would also make it easier to declare what is public, and what not.
Maybe a quick solution to that is to not declare the service-base module public. And split the module into smaller chunks for 1.2.x. We could still provide a "fat jar", composed of the other JARs for 1.2, to make it easier to migrate.
Hi Kai,
I still think there are a lot of interfaces/classes in service-base module that we should consider the public API. All device registry and device connection services definitions live there.
Sorry, forgot to add the links ...
Based on the discussions I had with Carsten regarding the changes
necessary for [1] I can now also imagine to only define the classes of
the core and client modules as part of Hono's Public API.
Dejan had already raised some concerns regarding the impact it would
have on our ability to quickly evolve, if we declared too much of our
code as part of the public API. I now see his point more clearly as it
would basically prevent us from making any reasonably complex changes to
any of our adapters without creating a new major release, which is
probably not what we want. Most of our adapters heavily depend on
classes in the service-base module so in order to make any substantial
progress we will need to change many of the classes in there.
In the past we had encouraged people to create custom protocol adapters
by means of extending some of the base classes in service-base. However,
in reality it seems more practical to use the approach outlined in [2]
in order to connect devices using a proprietary protocol to a Hono
system. Note that this approach does not require implementing a full
fledged custom protocol adapter.
I would therefore propose to also exclude the service-base module from
Hono's public API. People can still use it if they want to implement a
custom adapter but they should be aware that we might change the code at
any time.
WDYT?
[1] https://github.com/eclipse/hono/issues/1328
[2] https://github.com/eclipse/hono/issues/1478
Kai
On 15.01.20 14:22, Hudalla Kai (INST/ECS4) wrote:
> On 15.01.20 12:56, Dejan Bosanac wrote:
>> Hi Kai,
>>
>> this seems reasonable to me. Just one thing, when you say "all classes",
>> do you mean public methods signatures by that or something else?
>>
>
> Good point. I would say that this affects all public classes in the
> "public" packages which are currently
>
> core: all packages
>
> client: all packages
>
> service-base: all packages
>
> Does that make sense?
>
>> On Tue, Jan 14, 2020 at 8:52 AM Hudalla Kai (INST/ECS4)
>> <Kai.Hudalla@xxxxxxxx <mailto:Kai.Hudalla@xxxxxxxx>> wrote:
>>
>> Hi list,
>>
>> with Hono 1.0.0 having been released last year, we now need to follow
>> semantic versioning for its public API. So far so good. During the past
>> weeks while implementing new features, we already ran in to situations
>> where some refactoring would have been beneficial but where we had to
>> think twice about whether we can simply change a method's signature or
>> remove some obsolete class(es). I think we can all agree that this
>> depends on whether the affected artifacts are to be considered part of
>> Hono's public API or not.
>>
>> However, we haven't yet defined which parts of Hono actually constitute
>> its public API. Thus, I would like to propose a draft of what I would
>> consider (or like to see as) part of Hono's public API:
>>
>> 1) All remote APIs documented under [1]
>> 2) All classes in the core module
>> 3) All classes in the client module
>> 4) All classes in the service-base module
>>
>> IMHO the rest would then automatically not be public API and would thus
>> not be subject to semantic versioning.
>>
>> WDYT?
>>
>> [1] https://www.eclipse.org/hono/docs/api/
>>
>> --
>> Mit freundlichen Grüßen / Best regards
>>
>> Kai Hudalla
>>
>> Software Developer - Bosch IoT Hub
>>
>> Bosch.IO GmbH
>> Ullsteinstr. 128
>> 12109 Berlin
>> GERMANY
>> www.bosch.io <http://www.bosch.io>
>>
>> Registered Office: Berlin, Registration Court: Amtsgericht
>> Charlottenburg; HRB 148411 B
>> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
>> Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne
>> Reckling
>> _______________________________________________
>> hono-dev mailing list
>> hono-dev@xxxxxxxxxxx <mailto:hono-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/hono-dev
>>
>>
>>
>> --
>> Regards
>> --
>> Dejan Bosanac
>> http://sensatic.net/about
>>
>> _______________________________________________
>> hono-dev mailing list
>> hono-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/hono-dev
>>
>
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Software Developer - Bosch IoT Hub
Bosch.IO GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch.io
Registered Office: Berlin, Registration Court: Amtsgericht
Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne
Reckling
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
Jens Reimann
Principal Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
|
