Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

docs(faq): clarify the versioning strategy #15845

Merged
merged 3 commits into from
Mar 24, 2017
Merged

docs(faq): clarify the versioning strategy #15845

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e4ee119
docs(faq): clarify the versioning strategy
Narretz Mar 16, 2017
3384876
fixup! updates
Narretz Mar 24, 2017
df4ac0b
fixup! moar updates
Narretz Mar 24, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 17 additions & 7 deletions docs/content/misc/faq.ngdoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ We also allow breaking changes between beta releases of AngularJS.
For example between 1.4.0-beta.4 and 1.4.0-beta.5 there may be breaking changes. We try hard to minimize
these kinds of change only to those where there is a strong use case such as a strongly requested feature
improvement, a considerable simplification of the code, a measurable performance improvement, or a better
developer experience (especially with regard to updating to Angular).
developer experience (especially with regard to upgrading to Angular).

When we are making a release we generate updates to the changelog directly from the commits. This
generated update contains a highlighted section that contains all the breaking changes that have been
Expand Down Expand Up @@ -64,10 +64,10 @@ AngularJS code is separated into a main module ("angular"), and a few different
("angular-animate", "angular-route" etc) that are dependant on the main module.
When a new AngularJS version is released, all modules are updated to the new version.
This means that the main module and the optional modules must always have the exact same version,
down the patch number, otherwise your application might break.
down to the patch number, otherwise your application might break.

Therefore you must always explicitly lock down your dependencies, for example in the package.json,
the following ensures that "angular" and "angular-animate" are always updated to the same version.
the following means that "angular" and "angular-animate" are always updated to the same version:

```
{
Expand All @@ -76,14 +76,24 @@ the following ensures that "angular" and "angular-animate" are always updated to
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add another example where versions are really locked as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean locked down to the patch version without ~?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, to indicate that if you lock to a specific version, all versions need to be the same.

```

If you define exact versions, make sure core and optional modules are the same:

```
{
"angular": "1.6.3",
"angular-animate": "1.6.3"
}
```


#### How does AngularJS ensure code quality and guard against regressions?

When adding new code to branches of AngularJS, have a very stringent commit policy:
When adding new code to AngularJS, we have a very stringent commit policy:

- Every commit must contain tests and documentation updates alongside the code changes and that all the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and that all --> and all (?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and that all --> and all (or is it intentional?)

tests must pass;
- Commit messages must be written in a specific manner that allows us to parse them and extract the changes
for release notes.
for release notes ([see the contributing guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md)).

The AngularJS code base has a very large set of unit tests and end-to-end tests. This means that a breaking change will require one or more tests to be changed to allow the
tests to pass. So when a commit includes tests that are being removed or modified, this is a flag that the
Expand Down Expand Up @@ -130,8 +140,8 @@ Yes. See instructions in {@link downloading}.
### What browsers does AngularJS work with?

We run our extensive test suite against the following browsers: the latest versions of Chrome,
Firefox, Safari, and Safari for iOs, as well as Internet Explorer versions 9-11. See {@link guide/ie
Internet Explorer Compatibility} for more details on supporting legacy IE browsers.
Firefox, Safari, and Safari for iOs, Edge, as well as Internet Explorer versions 9-11. See
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iOs --> iOS

(Are we running against Edge yet?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not: issue #13687, PR #14401.

Yes, we should fix that. :D

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed it again. Edge had some problems with the script security checks last time i checked

{@link guide/ie Internet Explorer Compatibility} for more details on supporting legacy IE browsers.

If a browser is untested, it doesn't mean it won't work; for example, older Android (2.3.x)
is supported in the sense that we avoid the dot notation for reserved words as property names,
Expand Down