Update to 4.4

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?

[paddy-exe]

Contains changes to .gitignore file due to the addition of .uid files

Question is if we should add the .uid file?

[dsnopek]

Question is if we should add the .uid file?

Hm. If uid's are supposed to be unique, then I guess we shouldn't add the .uid files? Otherwise everyone who copies the template gets the same uid's, whereas if we leave them out, then Godot generates new unique ones for each project

[Ivorforce]

I think .uid files should be part of godot-cpp repos. It will likely not matter in most cases, but having consistent IDs across installs will make it more transparent what's happening in possible error reports or when an extension is removed and reinstalled.

If uid's are supposed to be unique [...]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

[dsnopek]

I think it's fine as long as they're unique within one project. I don't see a reason to have them be unique outside of it. Though perhaps I'm missing something about their design that would warrant that.

Well, if the .gdextension file in the template gets a .gdextension.uid, and multiple people make GDExtensions via the template and distribute them on the asset library, we could end up with multiple GDExtensions on the asset library having the same uid in their .gdextension.uid.

I'm not sure it would even actually cause problems, but I think we'd want to try and discourage something like that from happening.

The test project within godot-cpp itself should have it's .uid files saved in the repo, though. I don't think it does currently.

[unvermuthet]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

[paddy-exe]

I think they should be excluded from the template and regenerated. But adding them to the .gitignore seems like a bad idea. They should be committed once regenerated by the user. Is the a way to do this in .gitattributes?

I mean we could alternatively just not commit it here. That would make it easier. The downside is that we will have to make sure it won't ever be committed in the future. Not sure how this might be possible via gitattributes though

[paddy-exe]

Alright updated to not include the .uid file as discussed in the GDExtension meeting.

[Ivorforce]

How about editing the min version from the .gdextension file?

[unvermuthet]

Not sure about the compatibility_minimum in .gdextension. We expect people to raise that themselves if they use APIs from newer versions, right? The parameter describes itself very well and everyone will touch that file.

[Ivorforce]

godot-cpp-template itself is using an API from 4.4, and the resulting GDExtension is thus compatible only with 4.4+ (before the PR, 4.3+). I think we should raise it because it's just incorrect if we don't.

The parameter describes itself very well and everyone will touch that file.

That's true, but funnily enough I didn't change it myself until a few months after I started working with GDExtension because I thought my extension might be 4.1 compatible and it wouldn't if I changed it. Although that's a problem that will probably be less likely to happen to anyone else once we start expanding the docs about things like these :D

[unvermuthet]

Then it seems I misunderstood backward compatibility with GDExtensions.

[dsnopek]

It's true that because we're using the 4.4 branch of godot-cpp, the resulting GDExtension would only load on Godot 4.4+ (and give an error message about it on earlier versions)

However, I think it'd be OK to leave the compatibility_minimum it the .gdextension file at 4.1. That way, if a developer wants to support an earlier version, it's only a matter of rolling godot-cpp back to an earlier version, and doesn't require changing the .gdextension file as well

[unvermuthet]

I think leaving it lower might be misleading then. Kind of like what @Ivorforce said:

I thought my extension might be 4.1 compatible and it wouldn't if I changed it.

I also thought this was the only safeguard. What's the reason for having this twice?

[dsnopek]

I also thought this was the only safeguard. What's the reason for having this twice?

The minimum_compatibility is checked by Godot, and it's done before ever trying to load the extension. It's the only way we have to deal with the compatibility break between 4.0 and 4.1, while avoiding crashes.

The second check is done by godot-cpp after the extension has been loaded, but before being initialized. This allows us to automatically derive the compatibility from the extension_api.json that was used, such that the extension developer doesn't need to manually put this into the .gdextension file. Not all extension bindings do something like this

[paddy-exe]

I could alternatively also put some more information into the steps of using the template that godot-cpp should be set to the minimum supported version?