This reverts commit ca81e6e42826956e1912665a8e8077ab0d9705be.
The reverted commit does not actually fix the ancestry problem for a given release and the change was adding an unnecessary merge operation as a result. Simply branching off of `develop` is sufficient to create history from `stable` to `develop`.
In a follow-up change, I will address the actual root problem of `develop` not having an ancestral relations to the `stable` release commits.
Prior to this change, our release process was merging `develop` directly into `stable` without first branching off of `stable`.
The result of this process was that `stable` shares no common ancestor with `develop`, making it difficult to calculate differences between a commit on `develop` and a commit on `stable`.
One example of where this becomes problematic is in generating internal CLs for our PRs and for `develop`. It is not possible to compute the delta between the most recent `stable` commit that was mirrored internally and a given `develop` commit, making it difficult for tooling to apply deltas to the internal codebase without simply blowing away the internal directory and checking out the desired `develop` commit.
To fix this problem, we need to create a common ancestor between `develop` and `stable`. To do so, when cutting a release we need to cut the `release-candidate` from `stable` rather than `develop`, and then immediately merge `develop` into the release-candidate. This creates a common ancestor between `develop` and `stable`.
Note that this change causes us to deviate from the pure git flow model we have historically been following, as shown in the before/after of the model below (note the new red lines connecting stable to develop).
| Before | After |
|:--|:--|
|  |  |
The problem is that when you have a fresh clone (and you're not doing a hotfix) the "branch" variable in `scripts/release` points to `origin/develop`. There is no notion of a local stable branch. So commands like the one this PR changes need to specify a remote.
Closes#8585.
To keep .gitattributes correct in both develop and stable branches, 2 additions were added, one to the cut and one to the merge steps.
In cut we checkout the .gitattributes from stable before opening the PR to merge from release-candidate to stable, as release-candidate was created from Develop, and therefore without checking out the .gitattributes version from stable, when merged it would take the develop version.
In merge, we do a no-commit merge and then reset the .gitattributes so that develop branch won't take the release-candidate/stable version.
Closes#8392
The release script was continuing after errors failed to generate the
correct local clone of the repository for the API Diff step. This is
because the main release script suppresses non-zero return codes by
default. Instead, we should explicitly exit of any command returns an
unhandled non-zero value.
The `scripts/release apidiff` command needs to create two local temporary clones of the repo in order to generate the API diff. Unfortunately, git lfs fails to clone local copies of a git repo, particularly when not using a `file://` prefix.
The fix is to disable git LFS cloning prior to the API diff temporary clone commands.
```bash
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent. See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent. See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent. See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent. See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Downloading snapshot_test_goldens/goldens_64/MDCCardSnapshotTests/testDefaultCard_11_2@2x.png (1.9 KB)
hint: The remote resolves to a file:// URL, which can only work with a
hint: standalone transfer agent. See section "Using a Custom Transfer Type
hint: without the API server" in custom-transfers.md for details.
Error downloading object: snapshot_test_goldens/goldens_64/MDCCardSnapshotTests/testDefaultCard_11_2@2x.png (96d48d5): Smudge error: Error downloading snapshot_test_goldens/goldens_64/MDCCardSnapshotTests/testDefaultCard_11_2@2x.png (96d48d51f415dc94427e49a361cf68cdadc86d0e00a6706894a7f82b5d13b086): batch request: missing protocol: "file:///Users/featherless/workbench/material-components-ios/.git/info/lfs"
Errors logged to /private/tmp/mdcios/mdc-ios/.git/lfs/logs/20181218T112727.676554.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: snapshot_test_goldens/goldens_64/MDCCardSnapshotTests/testDefaultCard_11_2@2x.png: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
```
This is an automated change generated by replacing all instances of MaterialComponentsAlpha with MaterialComponentsBeta. This is not a breaking change because changes to Alpha/Beta components (including renaming them) are not considered breaking.
The MaterialComponentsAlpha podspec was mistakenly named Alpha, when what we meant was more close to Beta. The distinction is that Alpha components are not expected to be used by clients, while Beta components are.
### Context
When determining whether a change affects multiple components we want to ignore changes to CocoaPods files that live outside of the components directories.
### The problem + fix
Prior to this change, if a commit modified MaterialComponentsAlpha.podspec or catalog/Podfile it was being picked up as a multi-component change in the release notes.
After this change, commits affecting those files will not be treated as multi-component changes unless they also touch other files in the repo.
### Opportunities for further improvement
It's likely fair to say that any modification to files outside of the `components/` directory can be ignored. I'm not sure what the best way to filter these types of changes is, but that would be a welcome follow-up simplification of this change that would require less on-going maintenance.
The script now outputs four groups of changelogs:
1. Breaking changes for specific components.
2. Breaking changes across multiple components.
3. Changes for specific components.
4. Changes acrosss multiple components.
Prior to this change, `Component+Extension` additions would be incorrectly listed as a "New component" in the API diff.
After this change, `Componet+Extension` additions will be listed as "New extension" in the API diff.
The umbrellas command is fed in to the apidiff tool as a filter for which components to look at.
Prior to this change, the umbrellas command was ignoring the apidiff base sha and always generating results from origin/stable.
After this change, the umbrellas and files commands will both accept an optional base sha from which to generate results.
Tested by running:
```bash
./scripts/release umbrellas HEAD
# Should output nothing
```
The release engineer is expected to fill these sections in by gathering the information from the commits. If information is not available in a given commit, then the release engineer is expected to reach out to the commit author and ask them to provide the additional information (and encouraging them to do so in their commits in the future).
This change ensures that our release notes include API diffs for sub-components such as our themers.
Closes https://github.com/material-components/material-components-ios/issues/3983
Example output:
### AppBar+ColorThemer
#### MDCAppBarColorThemer
*new* class method: `+applySurfaceVariantWithColorScheme:toAppBarViewController:` in `MDCAppBarColorThemer`
*new* class method: `+applyColorScheme:toAppBarViewController:` in `MDCAppBarColorThemer`
### AppBar
#### MDCAppBarContainerViewController
*new* property: `appBarViewController` in `MDCAppBarContainerViewController`
#### MDCAppBarNavigationControllerDelegate
*new* method: `-appBarNavigationController:willAddAppBarViewController:asChildOfViewController:` in `MDCAppBarNavigationControllerDelegate`
#### MDCAppBarViewController
*new* property: `navigationBar` in `MDCAppBarViewController`
*new* property: `headerStackView` in `MDCAppBarViewController`
*new* class: `MDCAppBarViewController`
The following changes were made:
- The global grep is now a non-regular expression search. This will avoid treating the version '.' as a wildcard.
- We ignore any of the bazel output directories.
- We pipe stderr to null so that invalid directories don't appear in the output.
* Switched to hard-coded version string.
* Updating to current version and clarifying comments.
* Updated bump script to update LibraryInfo source version.
* Added actual replacement to bump script.
* Documented constants, changed version file name to a path.
* Fixed single-value tuple issue.
* Added note about string copy.
CocoaPods updated their default install behavior some time ago to not update the pods repo, but our pods management script still appeared to be assuming that it did update the repo. This change inverts our pod install logic so that it updates the spec repo by default.
This resolves some Travis CI failures we've seen when downstream pod releases get published but not picked up by the Travis CI instance's pre-imaged pods repo.
