Review new apax version #4
Conversation
README.md
Outdated
|
|
||
| ## 06 Build | ||
| > Be aware : Adding the option `--globally` argument to the clean command will delete the actual package cache on "C:\Users\xxxxx\.apax\packages" in addition and not only the Symlink. |
There was a problem hiding this comment.
is that information relevant for the user?
There was a problem hiding this comment.
nope ... I delete it again ... let's keep it a clean cheat-sheet.
README.md
Outdated
| | ----------- | --------------------------------------------------------------------------------------------------------------- | | ||
| | `apax pack` | Create a package that can be published. Only files specified in the files section of the apax.yml are included. | | ||
|
|
||
| ### Options | ||
| > You can pack any kind of apax project/ repository. E.g. Library-, Application-, Workspace-, Catalog-, Template- or Generic-type. |
There was a problem hiding this comment.
I thin that information can be missed --> I think a basic understanding of packages should be given. Remind: it's just a cheat sheet. It should provide compact information.
There was a problem hiding this comment.
I aggree. But than I also leave out the basic understanding of an package. Having as less explaination in here as possible.
README.md
Outdated
| | `--keyVersion <VERSION>` | Optional add a version "v{number}" , default: "v1" . | | ||
| | `--ignore-scripts` | Do not run any pre~ and post~ scripts. For example prepack & postpack. | | ||
|
|
||
| > `apax pack` signs every package with `apax keygen`. If no `<KEY>` provided, a new key with v1 will be automatically generated in the process. |
There was a problem hiding this comment.
For my opinion it's not correct. The keygen will be called once. When any random key is created, no new key will be generated.
There was a problem hiding this comment.
Yeah this is my understanding as well ... maybe I wrote it down a little bit too ambiguous. I rewrite the sentence to get rid of that possible misunderstanding.
README.md
Outdated
| @@ -1,140 +1,178 @@ | |||
| # Apax Cheat Sheet | |||
|
|
|||
| ## 01 Apax initial work | |||
| ## Disclaimer | |||
There was a problem hiding this comment.
Call it 'Scope' instead of 'Disclaimer'
The scope for that cheat sheet is valid for apax 3.2.1
--> But how is the Idea... Will you create for each apax version a new tag (by the way: it not a branch-tag)? What, when apax 3.2.1 and 3.2.1 is equal regarding the functionality?
Is it better to use semantic versioning e.g.: ~3.2.0 ? --> Finally, you've just one tag for 3.2.X. Otherwise you need to create a new tag for each bugfix.
There was a problem hiding this comment.
Good point, I will call it "Scope".
Regarding the release: Na. For each version a new tag would be to much of an effort. Would rather have it as for each feature version, like you already stated. Let's do it like that ... creating a release of that repo starting with 3.2.0.
| | `install` arguments | description | | ||
| | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `--ignore-scripts` | Do not run any pre~ and post~ scripts. For example preinstall & postinstall. | | ||
| | `--install-strategy <STRATEGY>` | Define apax install strategy `strict` (default) or `overrideable`. Not mention this argument will always fall back to the default or whats defined in the apax.yml. | |
There was a problem hiding this comment.
maybe a short comment regarding the install strategy --> what's the difference between strict and overrideable:
Strict:
- Strict adherence to version requirements.
- Errors if versions do not match
Overridable:
- More flexible approach to find a compatible version.
- Attempts to satisfy the most requirements, even if not all are strictly met.
There was a problem hiding this comment.
i added a comment
|
review changes have been committed :-) |
| | `apax add <PACKAGE>` | | The name of the package to add to the projects apax.yml `depencencies`. It calls implicit an `apax install`. | | ||
| | `apax add <PACKAGE> --dev` | `-D` | Whether to add the package as a `devdepencencies` instead. It call implicitly a `apax install`. | | ||
| | `apax add <CATALOG> --catalog` | | Add the catalog to the catalogs section. It do NOT call implicitly a `apax install --catalog`. | | ||
|
|
There was a problem hiding this comment.
apax add @Package@version is missed. example: apax add @ax/[email protected]
Updated the readme.md to fit apax 3.2.1 behaviour .. added missing / new apax commands .. cleaned repository ... added .pdf variant of readme.md