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

Refactoring: stack type goes better in a separate library #278

Open
acmenezes opened this issue Oct 18, 2022 · 1 comment
Open

Refactoring: stack type goes better in a separate library #278

acmenezes opened this issue Oct 18, 2022 · 1 comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. refactor
Milestone

Comments

@acmenezes
Copy link
Contributor

Since the stack type is generic and not necessarily related to capability we could use a different package to hold those types an allow it to be imported from multiple other points or even externally since it's pretty useful for many cases. Instead of having it on internal/capabilities/types.go we could provide a different package not sure what name and what this package could hold though.

@acmenezes acmenezes added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Oct 18, 2022
@acmenezes acmenezes added this to the Basic Install - v0.2.0 milestone Oct 18, 2022
@skattoju skattoju self-assigned this Oct 20, 2022
@skattoju
Copy link
Contributor

#293 is a draft PR suggesting moving it to internal/types/stack.go what do you think ?

@skattoju skattoju removed their assignment Nov 8, 2022
@acmenezes acmenezes modified the milestones: v0.2.0, v0.3.0 Dec 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. refactor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants