Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Version 3.0.1+1 #689

Merged
merged 1 commit into from
Oct 15, 2021
Merged

Version 3.0.1+1 #689

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 6 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,9 @@
#### 3.0.1+1 - 2021-10-14
Copy link
Member

Choose a reason for hiding this comment

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

FYI 3.0.2 would have been more idiomatic.

https://github.com/dart-lang/sdk/wiki/External-Package-Maintenance#bumping-versions

Copy link
Member Author

@cbracken cbracken Jan 4, 2022 •
edited

Choose a reason for hiding this comment

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

Oh weird. TIL!

Out of curiosity, when did this rule change? We'd been doing this for years for "no functional effect" changes like documentation, as had other packages like vm_service, dart_style, async, etc. Might be worth sending out a note to the dart/flutter teams.

Copy link
Member

Choose a reason for hiding this comment

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

There was a bunch of confusion years ago about the intended patterns. Some packages only used +1 version changes for 0.x releases, while other packages kept using them after the 1.x release for doc changes.

Copy link
Member Author

Choose a reason for hiding this comment

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

SGTM - glad we've got a clearly documented policy now!


* Add documentation to `Optional` suggesting that adding new uses be avoided
and existing uses should be migrated to nullable types in codebases where
non-null by default has been enabled.

#### 3.0.1 - 2021-04-06

* Fix: Eliminate null check error on removal of root node of
Expand Down
7 changes: 4 additions & 3 deletions lib/src/core/optional.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,9 +19,10 @@ import 'dart:collection';
/// Use Optional as an alternative to allowing fields, parameters or return
/// values to be null. It signals that a value is not required and provides
/// convenience methods for dealing with the absent case.
//
// TODO(cbracken): Consider making this Optional<T extends Object>.
// See: https://github.com/google/quiver-dart/issues/666
///
/// With the introduction of non-null by default in Dart SDK 2.12, developers
/// should avoid adding more uses of this type. Existing users should migrate
/// away from the `Optional` type to types marked nullable: `T?`.
class Optional<T> extends IterableBase<T> {
/// Constructs an empty Optional.
const Optional.absent() : _value = null;
Expand Down
2 changes: 1 addition & 1 deletion pubspec.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ description: >-
Quiver is a set of utility libraries for Dart that makes using many Dart
libraries easier and more convenient, or adds additional functionality.
repository: https://github.com/google/quiver-dart
version: 3.0.1
version: 3.0.1+1

environment:
sdk: '>=2.12.0-0 <3.0.0'
Expand Down