-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Bumped engine version to 1.5 #3749
Conversation
1.5 will be the development stage, and the next release will be 1.6
imo it's worth to apply some bugfixes before closing that chapter |
it wont be closed, it will still receive bug fixes, we are changing it to 1.5 just to differentiate release from development |
Maybe we should just put I know we discussed that before and that was agreed upon, however using 1.5 as undetermined/unreleased indicator is still not helpful. It needs to be replaced at release time regardless. |
Hmm, is it possible to make it 1.5_YearMonth? (Where YearMonth represents the time it was compiled, or last commit?)
Technically, this would make it more difficult, because we wouldn't be able to easily distinguish etc version 1.5 and 1.7 if they are both development versions just known as master. Then I would flag it at least as 1.5_dev or 1.5_master or 1.5_git to emphasis that its in the middle of a dev process.
That chapter exist in this branch: This is a sample PR that submits specifically to the 1.4 branch: (1.4.1 release candidate). We can continue to cherry pick and merge bugfixes into that branch and make 1.4.x subversions. This allows us to merge in new features into 1.5 without worrying too much about breaking a release branch. I imagine we should also make a 10.98 protocol branch once we start to merge in protocol 12 stuff, at least for a while until master gets healthy again. (We should never merge unhealthy code, but you know how it goes...). |
You're overcomplicating this. |
The version isn't there to help distinguish anything. 1.5_dev is just as vague as anything else, and it's wrong. We do not need to duplicate that effort manually. |
Hmm ok, but we should definitely merge a change to |
@Znote I can't find it, could you tag it? |
What I meant is that I don't think we should merge in protocol 12 into what is currently considered version 1.4. So we should merge this PR first, or change it to master and merge it before we introduce protocol 12. @DSpeichert |
1.5 will be the development stage, and the next release will be 1.6
Pull Request Prelude