Release 3.2.0#1338
Merged
Merged
Conversation
The temporary fixes in polybar.git's prepare() function can be removed because they are now part of the release
Member
|
Sounds good. It might also be nicer to do more frequent minor releases because we usually end up having a large backlog of features, fixes, etc. We should have some metric to determine when to release, especially if some PRs in the milestone take longer than expected. |
NBonaparte
approved these changes
Jul 22, 2018
Member
Author
|
I agree, we should maybe limit our milestones to 5 or 6 features and if they're done, just do a release. If only one of them is holding the others back, we just move it to the next milestone and continue with the release. |
Member
Author
|
Will try to finally release this thing tomorrow and nicely write up the release guidelines. |
Member
Author
|
I have written down the guidelines in the wiki, if you want to read them |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I think the 3.2.0 release is badly needed right now, for one because xcb-proto 1.13 is getting more and more common, making the 'eventstruct' issue (#973) catch on (see #1335, #1330, #1294, #1252, #1233, #1090, #1114) and also 3.1.0 cannot be compiled with gcc 8 without manually updating the i3ipcpp submodule.
The 3.2.0 Milestone contained quite a few unfinished issues, I have moved almost all of them into the 3.3.0 Milestone because this release now has some urgency to it.
The only issue I kept was #1194, because there is already a fix for it (#1198), it just needs to be reviewed and merged.
With this release, I'd like to also propose some guidelines on how we do releases. The base idea is that each minor (and major) release (like 3.0.0, 3.1.0, 3.2.0, etc) gets its own branch. The name of the branch is the version number with the patch number dropped (e.g. 3.2, 4.0, etc) so that we don't get any conflicts with the git tags for the versions (that's why in the README I used
--branch 3.2). Development continues onmaster, no actual work is done directly in the release branches. If we need to release a patch version (e.g. 3.2.1), for example because of a critical bug, we cherry-pick the commit that fixes the bug onto the current release branch (Note: The 3.2.1 tag is only present in the release branch, themasterbranch now only contains the tags for minor and major releases). So we basically backport the fixes, this way we don't have to create minor releases for every bug, just because we implemented a feature in the meantime. It also prevents the behaviour we have now, where we have to patch up the PKGBUILDs and write extra instructions just to get the current version to compile.I'd like to get your feedback on these release guidelines, if you approve, I will write a page on the wiki with a release protocol.
Things to do before merging:
Things to do after this is merged:
(unreleased)note from new features in the wiki3.2branch with this PR as its base commit.3.2branch@NBonaparte could you please review #1198 so that we can fix that bug for this release.