Re: [hono-dev] Definition of Hono's public API

[Julian Feinauer <j.feinauer@xxxxxxxxxxxxxxxxx>]

Hey Kai,

they are self defined by the project, not from the JRE or some third party lib.
You can find the here:
https://github.com/apache/flink/blob/549079c0b565d10faf07272bdbe046a9b451b086/flink-annotations/src/main/java/org/apache/flink/annotation/Experimental.java
and the others (Public, PublicEvolving, ...) here
https://github.com/apache/flink/tree/549079c0b565d10faf07272bdbe046a9b451b086/flink-annotations/src/main/java/org/apache/flink/annotation

Best
Julian

Am 14.01.20, 09:51 schrieb "hono-dev-bounces@xxxxxxxxxxx im Auftrag von Hudalla Kai (INST/ECS4)" <hono-dev-bounces@xxxxxxxxxxx im Auftrag von Kai.Hudalla@xxxxxxxx>:

    On 14.01.20 09:02, Julian Feinauer wrote:
    > Hi Kai,
    > 
    > although I'm not part of the active Hono Development and barely a User I like how some projects use Annotations like @Experimental or @StableApi to signal their users which part of the interface is considered stable and which could change even with minor revisions.
    > For Example Apache Flink did that a lot (I don’t know if thei're still doing it).
    > 
    
    Thanks for the hint. Any pointer to the annotations you mentioned? Where
    do they come from?
    
    > And regarding your proposal, that sounds reasonable to me.
    > 
    > Julian
    > 
    > Am 14.01.20, 08:52 schrieb "hono-dev-bounces@xxxxxxxxxxx im Auftrag von Hudalla Kai (INST/ECS4)" <hono-dev-bounces@xxxxxxxxxxx im Auftrag von Kai.Hudalla@xxxxxxxx>:
    > 
    >     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
    >     
    >     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
    > 
    
    -- 
    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