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

How to do versioning? #91

Closed
lanwin opened this issue Feb 8, 2024 · 9 comments
Closed

How to do versioning? #91

lanwin opened this issue Feb 8, 2024 · 9 comments

Comments

@lanwin
Copy link
Owner

lanwin commented Feb 8, 2024

Since the codebase changes a lot recently there also a lot bugs and breaking changes. So we need a versioning strategy.

The best would be to have a tag an real version but that would be make more sens when there are news versions that are tested and getting developed over a longer time. Maybe later.....

Currently I think about walking with a main (dev) branch and a stable branch. The main has the latest changed but can be unstable. stable contains a mostly stable (expect from known bugs) branch witch gets merged then and when from main.

I would mention both in our example config.

But I am not sure if this is a good plan.

What do you think @atanasenko @matthias882 @bzumik1 @mbo18 @Foggy2 ?

@atanasenko
Copy link
Contributor

Yea I think that's a good plan. Maybe even add tags now and then before introducing larger changes.

@bzumik1
Copy link
Contributor

bzumik1 commented Feb 8, 2024

Hi @lanwin, I was reflecting on this today and believe it's an excellent idea. I suggest maintaining stability in the main branch and carrying out development activities in the dev branch, which is a common practice. Additionally, it would be beneficial to systematically track the features in both the main and dev branches.

@lanwin
Copy link
Owner Author

lanwin commented Feb 9, 2024

I am not sure. But for a project using a dev branch has the drawback of looking less active. Since most people look in the main branch for activity.

@lanwin
Copy link
Owner Author

lanwin commented Feb 9, 2024

For the uses this should be irrelevant since most people simply copying the example config with then points to stable.

@TCB13
Copy link
Contributor

TCB13 commented Feb 10, 2024

For future reference, this could be a good candidate for a stable release: #87 (comment)

@bzumik1
Copy link
Contributor

bzumik1 commented Feb 11, 2024

For the uses this should be irrelevant since most people simply copying the example config with then points to stable.

I see what you mean, than your approach is fine.

@mbo18
Copy link
Contributor

mbo18 commented Feb 11, 2024

Having 2 branches like you described is fine as long as users don’t have to change their configuration to get the latest stable code

@Foggy2
Copy link
Contributor

Foggy2 commented Feb 12, 2024

I agree it is a good idea.

I think @mbo18 has a valid point. Anyone that has deployed the project right now would be pulling from main and would end up being on dev if they do not change their configuration.

I think that either should be fine though because main is effectively a dev branch right now. So it should not make the experience any worse for existing users.

@lanwin
Copy link
Owner Author

lanwin commented Feb 13, 2024

Ok I have created a stable branch and an initial release. I plan to use date based release tag since I made good experiences with that in the past.

@lanwin lanwin closed this as completed Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants