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

Release of Che 7 Beta #12621

Closed
l0rd opened this issue Feb 6, 2019 · 7 comments
Closed

Release of Che 7 Beta #12621

l0rd opened this issue Feb 6, 2019 · 7 comments

Comments

@l0rd
Copy link
Contributor

l0rd commented Feb 6, 2019

Description

At the end of next sprint (in 3 weeks) we should release 2 versions/branches: 6.19.0/6.19.x and 7.0.0-beta.1.0/7.0.0-beta.1.x. Master branch should than use version 7.0.0-beta.2.0-SNAPSHOT and in branch 6.19.x we should only commit/cherry pick Che 6 fixes.

@riuvshin @benoitf @nickboldt what do you think?

@slemeur slemeur mentioned this issue Feb 6, 2019
69 tasks
@benoitf
Copy link
Contributor

benoitf commented Feb 6, 2019

no issue on my side

@nickboldt
Copy link
Contributor

nickboldt commented Feb 6, 2019

What happens if we need to do a che 6.20 or other future 6.x maintenance between now and August 2019? Would that be done in the 6.19.x branch? Or... do we need a 6.x branch in addition to 6.19.x and master branches.

Also, 7.0.x-Beta1 sounds like an odd way to branch - that implies the next build will be 7.0.1.Beta1. Should we have a 7.0.0.Beta1x branch instead, in case we need to do a 7.0.0.Beta1-1 ?

-1 for this plan. Suggest we need instead 2 tags and 4 branches:

  • 6.19.0 + 6.19.x and 6.x
  • 7.0.0-Beta1 + 7.0.0-Beta1x and master

@l0rd
Copy link
Contributor Author

l0rd commented Feb 6, 2019

What happens if we need to do a che 6.20 or other future 6.x maintenance between now and August 2019?

In what circumstances should we need a version 6.20.0? Can't we just release patch versions when and if we need to do a new "patch" release (e.g. 6.19.1, 6.19.2 etc...)?

do we need a 6.x branch in addition to 6.19.x and master branches.

Yes if we will need a 6.20.0 version we will need such a branch. But if we agree that we won't need it I assume we won't need a 6.x branch neither.

Also, 7.0.x-Beta1 sounds like an odd way to branch - that implies the next build will be 7.0.1.Beta1. Should we have a 7.0.0.Beta1x branch instead, in case we need to do a 7.0.0.Beta1-1 ?

You are right. Calling the branch 7.0.0.Beta1x is much better.

@l0rd
Copy link
Contributor Author

l0rd commented Feb 6, 2019

After looking at https://semver.org/#spec-item-9 I think we should call the version 7.0.0-beta.1.0 (and the branch 7.0.0-beta.1.x)

@nickboldt
Copy link
Contributor

nickboldt commented Feb 7, 2019

+0, What about something simpler like 7.0.0-beta1x, with only 3 x.y.z version segments? Do you really need 5 segments?

+1, If we're happy doing all future maintenance in 6.19.x branch, then I'm happy to not need a 6.x branch.

@l0rd
Copy link
Contributor Author

l0rd commented Feb 7, 2019

@nickboldt I am ok with 7.0.0-beta1x as well. Thanks for your feedbacks.

@riuvshin I would apreciate if you could provide you opinion on this approach.

@riuvshin
Copy link
Contributor

done

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

4 participants