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