This repository was archived by the owner on May 21, 2024. It is now read-only.
Feat/prep 2020.3 #1574
Merged
Feat/prep 2020.3 #1574
Conversation
This file contains 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
pattivacek
requested review from
lbonn,
eu-siemann,
mike-sul,
xcheng-here and
kbushgit
Codecov Report
@@ Coverage Diff @@
## master #1574 +/- ##
==========================================
+ Coverage 82.19% 82.21% +0.02%
==========================================
Files 189 189
Lines 11860 11860
==========================================
+ Hits 9748 9751 +3
+ Misses 2112 2109 -3
Continue to review full report at Codecov.
|
This page is used as an include in another component; this was making the xrefs fail to resolve. Solution was to explicitly specify the component the links point to. (See https://docs.antora.org/antora/2.1/asciidoc/page-to-page-xref/ for more details on why this happens.) Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
…he steps Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: amma <awuraaamma.okyere-boateng@here.com>
Signed-off-by: Kostiantyn Bushko <kbushko@intellias.com>
Signed-off-by: Jon Oster <jon.oster@here.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
pattivacek
force-pushed
the
feat/prep-2020.3
branch
from
3da407c to
07a2255
Compare
|
This is ready for review now. |
lbonn
reviewed
Feb 27, 2020
| @@ -33,6 +33,13 @@ This is also a good time to review the docs in general and to consider whether a | |||
|
|
|||
| The docs published as https://docs.ota.here.com/ota-client/latest/index.html[latest] in the OTA Connect Developer Guide are built from the most recent release's docs branch (`\{version}-docs`). There will very likely be changes from there that have not been pulled into master yet. Open up a PR to merge the previous release's docs into master, resolving any merge conflicts as needed. Once that PR is merged, you can move on to the next step. | |||
|
|
|||
| The cleanest way to do this (especially if there were multiple changes to the docs branch) is to merge the docs branch locally and then rebase on master to remove the merge commits: | |||
There was a problem hiding this comment.
Do we want to actually rebase in this case? I haven't followed the discussions on this workflow too closely but having different doc commits in two branches might cause problem.
@tkfu do you have an opinion on this?
There was a problem hiding this comment.
I don't expect it to be a problem:
- It's a relatively rare occurrence for us to update docs branches other than the latest release, and when we do, we're generally doing it with a cherry-pick anyway
- I think the procedure @patrickvacek is suggesting here is only for when you merge the latest docs branch into master for immediate creation of a new release, so I wouldn't really worry about different doc commits between a non-current docs branch and master; the new docs branch will have whatever commits you end up with after rebase, and those are the ones that you may end up merging back in later
I'm fine with it, and don't expect it to cause problems. As far as I can tell, though, the only actual reason to do a rebase is to make the commit history a little cleaner, so I don't really have any strong opinions here. If you'd prefer to leave in the merge commits that's cool too.
There was a problem hiding this comment.
Yeah, actually the ugliest part was that if you viewed the git history with git log --graph, you'd see these merge lines from previous releases. Not the worst, but it seemed unintuitive to me.
|
Looks good apart from the workflow question. |
lbonn
approved these changes
Feb 27, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 probably want to wait until #1571 is merged, but I at least got this started.