This method works.. it is a lot easier if used with namespaces as the "set"
of changed objects are wrapped in a versioned namespace. This is a lot
easier for a user to map to, then having a lot of different versioned
objects.
The end result is that the user will map to a space like ats_8 that is an
alias for something like ats_8.1.0. GIven the code need to be recompiled
the user just gets something that works. If there is a breakage the user
can compile the plugin to a more exact version. The namespace allows this
to work all the objects in a release and if more advanced stuff is needed
they can still do it at a per-object level. However here the objects will
not be all over the place
Jason
On Fri, Jun 15, 2018 at 1:32 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Jun 15, 2018, at 11:38, Walt Karas <wka...@oath.com.INVALID> wrote:
> >
> > It potentially could allow moving to a new major release without the
> > need to immediately update all one's plugins.
> >
> > Are there any TS users that continuously deploy from master and don't
> > wait for releases?
>
> None that I know of.
>
> Still sounds like we’d add complexity to solve a problem that doesn’t
> exist. And now developers have to know which version of an include to use?
> Not to mention us managing multiple versions of these APIs.
>
> I say just bite the bullet once a year (possibly), for the last 10 years
> that has worked fine AFAIK. Its not like we make such changes frequent
> either. If it’s an issue , make a tool that updates code automatically for
> your in-house plugins. We did that once before, when we made major API
> changes.
>
> Ciao,
>
> — Leif
> >
> >> On Fri, Jun 15, 2018 at 12:04 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >> Hmmm, this sounds awful :). What is the intent / problem solved here?
> >>
> >> We can break APIs between major versions, so why do we need this?
> >>
> >> — leif
> >>
> >>
> >>> On Jun 15, 2018, at 11:00 AM, Walt Karas <wka...@oath.com.INVALID>
> wrote:
> >>>
> >>> We could have a ts2.h include file that included ts.h. It would
> >>> contain stuff like:
> >>>
> >>> #define TSExistingStructType TSExistingStructTypeVer2
> >>>
> >>> typedef struct
> >>> {
> >>> ... fields ...
> >>> } TSExistingStructTypeVer2;
> >>>
> >>> #define TSExistingAPIFunc TSExistingAPIFuncVer2
> >>>
> >>> void TSExistingAPIFuncVer2(... formal parameter list ...);
> >>>
> >>> As well as new declarations / definitions. Once all plugins were
> >>> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
> >>> ts2.h would become a symbolic link to ts.h. Once all plugins were
> >>> changed back to including ts.h, the symbolic link could be removed.
> >>>
> >>> There could hypothetically be multiple layers using this approach.
> >>> There could be a ts3.h include file that includes ts2.h. I could
> >>> contain stuff like
> >>>
> >>> #undef TSExistingAPIFunc
> >>> #define TSExistingAPIFuncVer3
> >>>
> >>> void TSExistingAPIFuncVer3(... formal parameter list ...);
> >>>
> >>> Clearly there are some API changes where this approach would not work,
> >>> but many where it would work.
> >>>
> >>> One way I'm thinking I would like to use this approach is to
> >>> substitute multiple, more specific types for the TSMLoc type. The
> >>> goal is to have more compile time checking. Currently we rely on run
> >>> time checks, and there are also cases where a coding error could
> >>> result in undefined run time behavior (memory corruption).
> >>
>
>
