Conversation
wfouche
changed the title
wfouche
changed the title
|
@maxandersen , ready to be reviewed and merged. |
| |*deciders* | ||
| a| | ||
| // list everyone involved in the decision | ||
| * Max Anderson |
There was a problem hiding this comment.
| * Max Anderson | |
| * @maxandersen |
There was a problem hiding this comment.
Fixed with Asciidoc update:
- https://github.com/maxandersen[Max Andersen]
- https://github.com/quintesse[Tako Schotanus]
|
|
||
| A JBang alias can point to: | ||
|
|
||
| Scripts:: Local files or remote URLs. |
There was a problem hiding this comment.
is this not repeating exactly same as whats on line 50 and down ?
|
|
||
| Nested Aliases:: Other aliases already defined within JBang catalogs. | ||
|
|
||
| A JBang Alias can also be called a JBang Application. And just like with any normal software application, users want to be able to use different versions of the same JBang Application. JBang however currently lacks a versioning mechanism for aliases. |
There was a problem hiding this comment.
I don't see it as JBang Alias can be called a JBang Application - its more that anything jbang can run can be called an application; not just scripts nor just aliases.
|
|
||
| Nested Aliases:: Other aliases already defined within JBang catalogs. | ||
|
|
||
| A JBang Alias can also be called a JBang Application. And just like with any normal software application, users want to be able to use different versions of the same JBang Application. JBang however currently lacks a versioning mechanism for aliases. |
There was a problem hiding this comment.
In this ADR we should call anything jbang can run/build/export an application (not just aliases) - in the code its called scriptref but its actually an appref so I'll use that below.
|
|
||
| In order for a user to select a specific version of a JBang Application the following commands must support application versioning. | ||
|
|
||
| * The `jbang app install <alias@catalog>` command should support application versioning. The version information should be optional, and if not provided, the latest version of the application should be installed. Otherwise, the requested version of the application should be installed. |
There was a problem hiding this comment.
just so its clear, alias (without @catalog) is also an alias.
|
|
||
| * The `jbang app install <alias@catalog>` command should support application versioning. The version information should be optional, and if not provided, the latest version of the application should be installed. Otherwise, the requested version of the application should be installed. | ||
|
|
||
| * The `jbang run <alias@catalog>` command should support application versioning. The version information should be optional, and if not provided, the latest version of the application should be executed. Otherwise, the requested version of the application should be executed. |
There was a problem hiding this comment.
| * The `jbang run <alias@catalog>` command should support application versioning. The version information should be optional, and if not provided, the latest version of the application should be executed. Otherwise, the requested version of the application should be executed. | |
| * The `jbang run <alias@catalog>` command should support application versioning. The version information should be optional, and if not provided, the version of the application the alias point to should be executed. Otherwise, the requested version of the application should be executed. |
i.e. if alias points to g:a:1.2 it should run that version, not g:a:LATEST
| This section outlines the ripple effects—both the wins and the new responsibilities—resulting from this change. | ||
|
|
||
| Positive: Reproducible Workflows:: | ||
| Users can now pin aliases to specific versions (e.g., jbang mytool:1.2.3@catalog), ensuring CI/CD pipelines and scripts don't break when a remote alias is updated. |
There was a problem hiding this comment.
This is promising a bit too much :) the remote alias being updated can still break ci/cd pipelines.
What this does is that the catalog does not need to have multiple versions listed
and users can override version even if catalog provider haven't add versions.
| Positive: Slight Decrease in Disk Usage:: | ||
| Since JBang will no longer fetch the latest version of an application, this would lead to fewer cached JARs and scripts. | ||
|
|
||
| Negative:: None that comes to mind. |
There was a problem hiding this comment.
more syntax to learn; but its all optional so wont disturb general usage.
| Performance Benchmark:: | ||
|
|
||
| Measure the delta in resolution time between a standard alias and a versioned alias to ensure no significant regressions in startup speed. | ||
|
|
There was a problem hiding this comment.
this ADR is missing how the version on the alias actually gets applied for the various types of application refs:
g:a:V (replace V)
alias:V@catalog
local files / http urls / GAV's (for it to work here we'll need some property replacement as version info is available in the urls)
2 participants
$ jbang run app:1.0.0@jbangdev --version1.0.0