| Re: [hono-dev] Definition of Hono's public API |
1.2 and 2.3 are completely incompatible.
1.2 is backward compatible with 1.1 for consumers but for providers it is incompatible. Consumers should therefore import [1.2,2)and providers should import [1.2,1.3)._______________________________________________No, that's a misunderstanding. I was only trying to set the scope at the
class level. I hope we can agree that we only want to include public
classes in the public API. Private members and methods should not be
affected, of course. However, protected members and protected non-final
methods of public classes can be overridden by subclasses and therefore
have to be considered part of the public API, right?Yeah, sorry missed that in your original email. It's clear now.I would go for the first option, i.e.
> The default would then be
> that protected members/methods are not public API unless marked as such
> explicitlySo would I. I think protected methods are more likely to be overridden by the Hono project itself, rather then 3rd party solutions. That's at least how I would like to see them. And of course, exceptions are possible.On Wed, Jan 15, 2020 at 3:43 PM Julian Feinauer <j.feinauer@xxxxxxxxxxxxxxxxx> wrote:Hi,
I would go for the first option, i.e.
> The default would then be
> that protected members/methods are not public API unless marked as such
> explicitly
But just a gut feeling.
Julian
Am 15.01.20, 15:23 schrieb "hono-dev-bounces@xxxxxxxxxxx im Auftrag von Hudalla Kai (INST/ECS4)" <hono-dev-bounces@xxxxxxxxxxx im Auftrag von Kai.Hudalla@xxxxxxxx>:
On 15.01.20 15:12, Hudalla Kai (INST/ECS4) wrote:
> On 15.01.20 15:01, Dejan Bosanac wrote:
>> This somehow went off the list ...
>>
>> But that would mean that even changes in the implementation of the
>> classes and changes to protected/private methods would trigger version
>> increment?
>
> No, that's a misunderstanding. I was only trying to set the scope at the
> class level. I hope we can agree that we only want to include public
> classes in the public API. Private members and methods should not be
> affected, of course. However, protected members and protected non-final
> methods of public classes can be overridden by subclasses and therefore
> have to be considered part of the public API, right?
>
However, we can also decide on a case by case basis for the protected
members/methods and mark those protected members/methods that we
consider part of public API accordingly, e.g. by means of JavaDoc or
annotations as proposed by Julian already. The default would then be
that protected members/methods are not public API unless marked as such
explicitly. Or we could do it the other way around, i.e. by default all
is public API unless marked as private explicitly. WDYT?
> I'm not sure going into such strict requirements would
>> bring us too much benefits.
>>
>> On Wed, Jan 15, 2020 at 2:14 PM Hudalla Kai (INST/ECS4)
>> <Kai.Hudalla@xxxxxxxx <mailto:Kai.Hudalla@xxxxxxxx>> 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>
>> <mailto: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> <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>
>> <mailto: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 <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
>> >
>>
>> --
>> 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
>>
>>
>>
>> --
>> 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