Code changes required after JDK-8291473

[Filip Krakowski]

Hi,

this sounds great! Once the changes get pushed I will include jextract's 
"panama" branch into our CI pipeline, so that we always have a version 
that is in sync with the latest "foreign-memaccess+abi" branch.

Thanks for the quick response! Looking forward to trying out it out :)

Best regards,
Filip

On 08.08.22 19:44, Maurizio Cimadamore wrote:
> After some internal discussion, we are going to do the following:
>
> * create a "panama" branch, which contains the changes needed to run 
> jextract with the API contained in the Panama repo
> * have (as now) a set of versioned branches, for jdk18 and jdk19
> * when 20 becomes GA, we will create a new jdk20 branch, copy the 
> contents of the "panama" branch into it and make it the default branch
> * we will _not_ provide binary snapshots for the "panama" branch, as 
> that's a "bleeding edge" sort of scenario (where you have to build the 
> panama repo manually to go with it as well)
>
> Cheers
> Maurizio
>
>
> On 05/08/2022 12:31, Maurizio Cimadamore wrote:
>> Hi Filip,
>> due to various complex reasons, it is currently not possible for us 
>> to release binary snapshots using GitHub actions. All the binaries we 
>> publish come from an internal CI pipeline, which builds and test 
>> using predefined, well-known configurations, so that we can ensure 
>> repeatable results. While this is not set in stone, and OpenJDK is 
>> relatively new to GitHub workflows, I think that, for the time being, 
>> we have to work with what we've got.
>>
>> That said, nothing prevents us from creating several internal 
>> pipelines, one per jextract version, and add a new one every 6 months 
>> or so, perhaps with some policy to "garbage collect" old pipelines 
>> (e.g. maybe providing binaries up to JDK N-3 would be a good starting 
>> point?) - although I'd have to check with the infra team and see what 
>> solution they'd be most comfortable with.
>>
>> P.S. While it would be possible, in principle, for 3rd parties to 
>> build snapshots of jextract, I find that solution less ideal. Plugins 
>> such as yours need a stable link to work with. A 3rd party build 
>> might be a great place to get started (or where to get more frequent 
>> jextract binary updates, for example), but doesn't provide (by 
>> design) that kind of long-term commitment that some of the tools in 
>> the ecosystem would require, at least IMHO.
>>
>> Thanks
>> Maurizio
>>
>> On 05/08/2022 11:23, Filip Krakowski wrote:
>>> Hi,
>>>
>>> is it a question of maintainability (diverging branches in case of 
>>> patches, etc.), which would stand in the way of this, or a question 
>>> of the infrastructure that would be required? In the latter case, I 
>>> could try to set something up to accomplish the job of automatically 
>>> creating releases from each pushed tag matching a version number.
>>>
>>> Since the project is hosted on GitHub, I could implement a GitHub 
>>> Action, which would be triggered on each pushed tag. This Action 
>>> would then compile the code for different platforms (Linux, macOS, 
>>> Windows - GitHub provides images for each), create a release inside 
>>> the repository and attach the created binaries to it. The repository 
>>> already contains a GitHub Action for building and testing jextract, 
>>> which I could use as a starting point.
>>>
>>> Best regards,
>>> Filip
>>>
>>> On 04.08.22 21:14, Maurizio Cimadamore wrote:
>>>>
>>>> On 04/08/2022 20:08, Filip Krakowski wrote:
>>>>> Each branch would therefore only produce binaries when it receives 
>>>>> a new tag. Could this work? 
>>>>
>>>> I'd have to check - my feeling is that, no that would not be possible.
>>>>
>>>> Another issue is that we'd need to keep updating the main github 
>>>> branch every few months (not a big issue).
>>>>
>>>> Maurizio
>>>>
>>>>
>>>