> 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).
>>
