Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking migration to updated metadata schema #200

Closed
34 of 98 tasks
luzpaz opened this issue Jan 15, 2022 · 11 comments
Closed
34 of 98 tasks

Tracking migration to updated metadata schema #200

luzpaz opened this issue Jan 15, 2022 · 11 comments

Comments

@luzpaz
Copy link
Collaborator

luzpaz commented Jan 15, 2022

Background

Thanks to @chennes we have a really robust way to categorize and systematize addons/macros/preference packs. So this thread will track the progress of getting addon devs to migrate to it.

Workbenches

@DeepSOIC
Copy link

<date>

REQUIRED

The date of the last update, in the format YYYY-MM-DD or YYYY.MM.DD.

Am i now supposed to update it upon every commit to my workbench? Because that sounds like a bit of a git merge conflict generator, apart from being an easy-to-forget red-herring...

i'm sorry if it's a stupid question or not the right place to discuss it. I didn't instantly find it at the forum at least.

@chennes
Copy link
Member

chennes commented Jan 19, 2022

The idea isn't to update it every commit, but every time you change the version number.

@DeepSOIC
Copy link

@chennes oh, wait, do i have to change the version number for every commit too?

@chennes
Copy link
Member

chennes commented Jan 19, 2022

You can do whatever you want with the version number, I don't think we want to get in the business of telling developers how they have to do that. I'm working on some new code now to better handle displaying the last commit date, and that will also enable better update handling for both git and non-git users. So don't worry too much about it right now.

@davesrocketshop
Copy link

Rocket workbench updated

@luzpaz
Copy link
Collaborator Author

luzpaz commented Jan 20, 2022

@chennes should we fork @triplus's repos to the FreeCAD organization and maintain them ?

@chennes
Copy link
Member

chennes commented Jan 20, 2022

It would probably be better if there were a specific human being who was interested in maintaining some or all of them. I haven't seen triplus around in a year or two, but I don't know the story there.

@chennes
Copy link
Member

chennes commented Jan 20, 2022

On a different note, Pyrate has the metadata file in their official repo on Debian Salsa. I have not ever tried to have two different submodules with the same name, though, so I don't know how to handle that. 0.19.3 supports Salsa now, but nothing before that does. I don't know when we want to pull the trigger on making that shift.

@luzpaz
Copy link
Collaborator Author

luzpaz commented Jan 21, 2022

I think I may be able to find some volunteers. I'll start a tracking ticket.

Edit: #202

@luzpaz
Copy link
Collaborator Author

luzpaz commented Jan 21, 2022

I have not ever tried to have two different submodules with the same name, though, so I don't know how to handle that.

Oy vey, here comes the complexity.

luzpaz added a commit to luzpaz/Part-o-magic that referenced this issue Mar 12, 2022
DeepSOIC pushed a commit to DeepSOIC/Part-o-magic that referenced this issue Mar 19, 2022
@luzpaz
Copy link
Collaborator Author

luzpaz commented Apr 13, 2023

I guess we should close this ticket?

@luzpaz luzpaz closed this as completed Aug 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants