Updated files for publishing.

CHANGELOG.md

@@ -1,4 +1,4 @@
-# Change Log
+# Changelog
 
 All notable changes to the project `CrossFileManager` will be documented in this file.
 See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.

CODE_OF_CONDUCT.md

@@ -14,22 +14,22 @@ appearance, race, religion, or sexual identity and orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
 
 ## Our Responsibilities
 
@@ -68,9 +68,9 @@ members of the project's leadership.
 ## Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
 
 [homepage]: https://www.contributor-covenant.org
 
 For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq
+<https://www.contributor-covenant.org/faq>

CONTRIBUTING.md

@@ -6,78 +6,87 @@ please read these instructions carefully.
 ## Contribution types
 
 ### Bug Reports
- - If you find a bug, please first report it using [Github issues].
-   - First check if there is not already an issue for it; duplicated issues will be closed.
+
+- If you find a bug, please first report it using [Github issues].
+  - First check if there is not already an issue for it; duplicated issues will be closed.
 
 ### Bug Fix
- - If you'd like to submit a fix for a bug, please read the [How To](#how-to-contribute) for how to
-   send a Pull Request.
- - Indicate on the open issue that you are working on fixing the bug and the issue will be assigned
-   to you.
- - Write `Fixes #xxxx` in your PR text, where xxxx is the issue number (if there is one).
- - Include a test that isolates the bug and verifies that it was fixed.
+
+- If you'd like to submit a fix for a bug, please read the [How To](#how-to-contribute) for how to
+  send a Pull Request.
+- Indicate on the open issue that you are working on fixing the bug and the issue will be assigned
+  to you.
+- Write `Fixes #xxxx` in your PR text, where xxxx is the issue number (if there is one).
+- Include a test that isolates the bug and verifies that it was fixed.
 
 ### New Features
- - If you'd like to add a feature to the library that doesn't already exist, feel free to describe
-   the feature in a new [GitHub issue].
-   thoughts.
- - If you'd like to implement the new feature, please wait for feedback from the project maintainers
-   before spending too much time writing the code. In some cases, enhancements may not align well
-   with the project objectives at the time.
- - Implement the code for the new feature and please read the [How To](#how-to-contribute).
+
+- If you'd like to add a feature to the library that doesn't already exist, feel free to describe
+  the feature in a new [GitHub issue].
+  thoughts.
+- If you'd like to implement the new feature, please wait for feedback from the project maintainers
+  before spending too much time writing the code. In some cases, enhancements may not align well
+  with the project objectives at the time.
+- Implement the code for the new feature and please read the [How To](#how-to-contribute).
 
 ### Documentation & Miscellaneous
- - If you have suggestions for improvements to the documentation, tutorial or examples (or something
-   else), we would love to hear about it.
- - As always first file a [Github issue].
- - Implement the changes to the documentation, please read the [How To](#how-to-contribute).
+
+- If you have suggestions for improvements to the documentation, tutorial or examples (or something
+  else), we would love to hear about it.
+- As always first file a [Github issue].
+- Implement the changes to the documentation, please read the [How To](#how-to-contribute).
 
 ## How To Contribute
 
 ### Requirements
+
 For a contribution to be accepted:
 
-- Documentation should always be updated or added.*
-- Examples should always be updated or added.*
-- Tests should always be updated or added.*
+- Documentation should always be updated or added.\*
+- Examples should always be updated or added.\*
+- Tests should always be updated or added.\*
 - Format the Dart code accordingly with `flutter format`.
 - Your code should pass the analyzer checks `melos run analyze`.
 - Your code should pass all tests `melos run test`.
 - Start your PR title with a [conventional commit] type
   (`feat:`, `fix:` etc).
 
-*When applicable.
+\*When applicable.
 
 If the contribution doesn't meet these criteria, a maintainer will discuss it with you on the issue
 or PR. You can still continue to add more commits to the branch you have sent the Pull Request from
 and it will be automatically reflected in the PR.
 
 ## Open an issue and fork the repository
- - If it is a bigger change or a new feature, first of all
-   [file a bug or feature report][GitHub issues], so that we can discuss what direction to follow.
- - [Fork the project][fork guide] on GitHub.
- - Clone the forked repository to your local development machine
-   (e.g. `git clone [email protected]:<YOUR_GITHUB_USER>/cross_file_manager.git`).
+
+- If it is a bigger change or a new feature, first of all
+  [file a bug or feature report][GitHub issues], so that we can discuss what direction to follow.
+- [Fork the project][fork guide] on GitHub.
+- Clone the forked repository to your local development machine
+  (e.g. `git clone [email protected]:<YOUR_GITHUB_USER>/cross_file_manager.git`).
 
 ### Performing changes
- - Create a new local branch from `main` (e.g. `git checkout -b my-new-feature`)
- - Make your changes.
- - When committing your changes, make sure that each commit message is clear.
- - Push your new branch to your own fork into the same remote branch
- (e.g. `git push origin my-username.my-new-feature`, replace `origin` if you use another remote).
+
+- Create a new local branch from `main` (e.g. `git checkout -b my-new-feature`)
+- Make your changes.
+- When committing your changes, make sure that each commit message is clear.
+- Push your new branch to your own fork into the same remote branch
+  (e.g. `git push origin my-username.my-new-feature`, replace `origin` if you use another remote).
 
 ### Open a pull request
+
 Go to the [pull request page of CrossFileManager][PRs] and in the top
 of the page it will ask you if you want to open a pull request from your newly created branch.
 
 The title of the pull request should start with a [conventional commit] type.
 
 Examples of such types:
- - `fix:` - patches a bug and is not a new feature.
- - `feat:` - introduces a new feature.
- - `docs:` - updates or adds documentation or examples.
- - `test:` - updates or adds tests.
- - `refactor:` - refactors code but doesn't introduce any changes or additions to the public API.
+
+- `fix:` - patches a bug and is not a new feature.
+- `feat:` - introduces a new feature.
+- `docs:` - updates or adds documentation or examples.
+- `test:` - updates or adds tests.
+- `refactor:` - refactors code but doesn't introduce any changes or additions to the public API.
 
 If you introduce a **breaking change** the conventional commit type MUST end with an exclamation
 mark (e.g. `feat!: Remove the argument from ZipLoader.getFile()`).
@@ -86,5 +95,4 @@ mark (e.g. `feat!: Remove the argument from ZipLoader.getFile()`).
 [GitHub issues]: https://github.com/signmotion/cross_file_manager/issues/new
 [PRs]: https://github.com/signmotion/cross_file_manager/pulls
 [fork guide]: https://guides.github.com/activities/forking/#fork
-[pubspec doc]: https://dart.dev/tools/pub/pubspec
 [conventional commit]: https://www.conventionalcommits.org

STYLEGUIDE.md

@@ -25,7 +25,7 @@ trailing comma.
 
 For the sake of example, let's use a function invocation (the same apply for all cases):
 
-```
+```dart
 // good
 foo(p1, p2, p3)
 
@@ -56,18 +56,18 @@ foo(f1,
 
 ### Imports
 
-* Never include unused or duplicated imports.
-* You must always use relative imports for imports within the CrossFileManager library
+- Never include unused or duplicated imports.
+- You must always use relative imports for imports within the `CrossFileManager` library
   (internal imports must be relative).
-* Omit `./` for relative imports from the same directory.
-* Avoid importing groups of APIs internally.
-* Order your imports by:
-    * Three main blocks, each separated by exactly one empty line:
-        * Dart SDK dependencies,
-        * External libraries/Flutter imports,
-        * Internal (same library) imports.
-    * Then, for each block, order alphabetically.
-        * For relative imports, that means further away (more `../`) imports will be first.
+- Omit `./` for relative imports from the same directory.
+- Avoid importing groups of APIs internally.
+- Order your imports by:
+  - Three main blocks, each separated by exactly one empty line:
+    - Dart SDK dependencies,
+    - External libraries/Flutter imports,
+    - Internal (same library) imports.
+  - Then, for each block, order alphabetically.
+    - For relative imports, that means further away (more `../`) imports will be first.
 
 ## Code Structure
 
@@ -81,17 +81,17 @@ Use asserts to detect contract violation.
 
 Example:
 
-````dart
+```dart
 void something(int smaller, int bigger) {
   assert(small < bigger, '`smaller` is not smaller than `bigger`');
   // ...
 }
-````
+```
 
 ## Comments
 
-* For any `//` comments, always add a space after the second slash and before the next character.
-* Use `//` (or block comments) for comments about the code; use `///` for dartdocs about APIs.
+- For any `//` comments, always add a space after the second slash and before the next character.
+- Use `//` (or block comments) for comments about the code; use `///` for dartdocs about APIs.
 
 ### TODO
 

example/pubspec.yaml

@@ -2,6 +2,11 @@ name: example_cross_file_manager
 description: An example for CrossFileManager.
 homepage: https://github.com/signmotion/cross_file_manager
 
+# Format:
+#   version: major.minor.patch
+# You can calculate the number version code by this formula:
+#   code = m[A]jor * 100 * 100 + m[I]nor * 100 + [P]atch
+# Otherwise: +AAIIPP
 version: 0.4.1
 
 publish_to: none

pubspec.yaml

@@ -2,6 +2,11 @@ name: cross_file_manager
 description: Can read files from assets, Internet (by URL), zip archives by loader priority.
 homepage: https://github.com/signmotion/cross_file_manager
 
+# Format:
+#   version: major.minor.patch
+# You can calculate the number version code by this formula:
+#   code = m[A]jor * 100 * 100 + m[I]nor * 100 + [P]atch
+# Otherwise: +AAIIPP
 version: 0.4.1
 
 environment: