[PHP 8.2] - Please tag a release for 7.x-1.11 based on the latest 7.x-1.x-dev

Please review / comment on the other open issues for the D7 branch.

This issue is the only commit since the previous release. I'm sure this issue is important to YOU, but there are many other open issues that are important to other users of the Entity API module. Please be part of the community and comment on / review those other open issues so that the next release benefits more than just the few who are looking at this particular issue.

I think there should be a full release made right away. 📌 PHP 8.2 - Fix deprecated dynamic properties Fixed is the only issue holding back compatibility with PHP 8.2. It would be very helpful to get that released. Lots of modules depend on this one, so all those modules are also being held back from having PHP 8.2 compatibility.

@TR the current dev is fine , I would be happy with a tagged release of the current dev for the sake of PHP 8.2 compatibility, we know it's working quite well (I've used the dev version of entity_api quite a bit already).

With that said, this issue seems like a fairly ubiquitous/safe/simple improvement to make that is 11 years old and has zero complaints.
🐛 PHP Fatal error: Class name must be a valid object or a string in drupal-7.14/includes/common.inc on line 7680 RTBC

IMHO PHP 8.2 compatibility is important enough to merit a tag and a release on it's own
📌 PHP 8.2 - Fix deprecated dynamic properties Fixed

bumping this

Hi Guys,

Can we please push this change asap to 7.x.1.11, please

Hi Guys,

Can we please push this change asap to 7.x.1.11, please

+1 for a new release.

marking as RTBC,

Please find the maintainers on the project page → , click on their avatar, then look for the contact tab, send a friendly message of appreciation for this module along with a hyperlink to this issue requesting for the tagged release.

These same maintainers are likely in the Drupal slack, I suggest a friendly ping on there also.

@TR could you look at fixing the tag for 7.11.

It appears to be based on a feature branch commit (https://git.drupalcode.org/project/entity/-/commits/24c6c4f1ce838f4439b5...), rather than the 7.x-1.x branch (https://git.drupalcode.org/project/entity/-/commits/7.x-1.x).

This can probably be fixed by merging the tag into the branch.

Sorry. I don't think it can be fixed because a release was already made with the tag.

The good news is the7.x-1.11 release contains the correct code. But I think I have to tag a new release 7.x-1.12 on the correct branch to fix the problem. The 7.x-1.12 release will be identical to the 7.x-1.11 release.

You can fix it like this: Go to branch 7.x-1.x and run git merge 7.x-1.11. That will add everything in the tag into the 7.x-1.x branch. No need for another release.

A simple merge adds all those junk commits from the feature branch - those were for trial-and-error debugging of GitLabCI, had junk comments, and really shouldn't be put into the main branch commit history.

git merge 7.x-1.11 --squash won't work either.

Any suggestions for how to just move that tag onto the 7.x-1.x branch without messing up the commit history?

If you made a commit on 7.x-1.x that was identical to 7.x-1.11, an administrator could in theory delete and re-create the tag there. I don't know if they would do this, however. If not, merging the tag is probably the best bet even if it adds development commits.

Well I'd rather keep the history clean. And the issue of a misplaced tag has been raised many times by others, with the administrator responding that if there's a release attached to the tag then it can't be fixed.

Tagging a 7.x-1.12 release on the HEAD of the correct branch doesn't seem to have any downside.

@TR, the easiest way to squash commits like you want to do is to quite simply do a diff between the branches, this diff can be used to generate a patch. Use that new patch to make one commit whereever you want to make it.

Alternatively, depending on the situation, often times I use the cherry-pick command included in git.

Yeah, I know that ... but how does that help move a tag from a feature branch to the main branch? The code in the main branch HEAD is identical to the tagged code. No patch needed, no patch possible because they're identical. The tag is just on the wrong branch.

You can clone your own copy of Entity API and test out any ideas you have for moving a tag, but my searching and experimentation tells me it can't be done without doing a force delete and recreate of the tag. Which would be "A Bad Idea"™

There is no way to fix the messy commit history except to delete and re-create the tag. If that is not possible, then the messy history will be there anyway. It might as well be merged so that it can be seen in the GitLab network graph instead of the 7.x-1.11 tag being hidden.

Maybe this can help? In particular, check the comments under the accepted solution.
https://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-gi...

The only thing is, I don't know if there are any restrictions on Drupal's implementation of GitLab that allows force pushing a change (e.g. git push -f origin <tagname>).

I vote for merging as-is, even with many commits.

I think you will find that pushing the tag deletion will not work due to rules configured in GitLab.

Automatically closed - issue fixed for 2 weeks with no activity.