-
Notifications
You must be signed in to change notification settings - Fork 238
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.
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
Trim kerl list releases
#465
Trim kerl list releases
#465
Conversation
As per our README's Erlang/OTP support policy
I don't think we should artificially limit the list of valid releases but it think it would be helpful to mark which OTP releases we are "officially" supporting somehow - maybe with an asterisk like git branch? Also the list is ridiculously long now - it might be worthwhile to trim some of it that's really quite ancient by default - if you give like "all" as a parameter you get the entire list, otherwise, you get a shorter more recently set of releases by default |
Ok, so based on your comment:
In any case, do you think |
This all sounds excellent
I do think it should be the entire list - I wish there was a way we could not fetch it so often but afaik, there's no HEAD method we could use |
I have some scripts that parse the output of Maybe it could:
For example:
|
I think @garazdawi is not alone in having some tools that parse kerl's output so I think we need to continue to provide the entire list but I think these suggestions for pruning are helpful and good ones. The pruned list probably should include some text like "the full list of releases is available using the command ..." |
I understand the need to have output similar to what there is, right now, but that could potentially be controlled with a variable, which is, I guess, the purpose of |
Ok, so what I have until now is:
Does this seem to suit all identified use cases, @jadeallenx, @garazdawi? |
kerl list releases
This is a great summary! Yes let’s do this please |
@garazdawi, I'm moving in the direction of my previous comment (with @jadeallenx's blessing 😄) . Do let me know if there's something you think could be adjusted, otherwise I can also add you as a reviewer and then we can go over the final result together. |
Output for R13B03
...
R16B03_yielding_binary_to_term
17.0-rc1
...
18.0
...
19.0.1
...
20.1
...
21.2.1
...
22.3.4.26
...
26.1
Run './kerl update releases' to update this list from erlang.org Output for 17.5.6.10
18.3.4.11
19.3.6.13
20.3.8.26
21.3.8.24
22.3.4.26
23.3.4.19
* 24.3.4.13
* 25.3.2.6
* 26.1
Run './kerl update releases' to update this list from erlang.org
Run './kerl list releases all' to view all available releases
Note: * means "currently supported" Given the current implementation, this also means that e.g. when |
Can we have the star after the version so that it is an easy grep + awk to get the versions?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks good to me. I think maybe we should only list releases from 20 onwards personally. But I'm willing to hear reasons why we should include older releases (17 has barely baked map support, for example...)
kerl
Outdated
check_releases | ||
list_print "$2" | ||
list_print "$2" "$3" | ||
l=t stderr "Run '$0 update releases' to update this list from erlang.org" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're touching this area of code, I think this message should not mention the erlang.org website any more (since it really parses tags from github by default)
l=t stderr "Run '$0 update releases' to update this list from erlang.org" | |
l=t stderr "Run '$0 update releases' to update this list" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kerl
Outdated
} | ||
END { | ||
if (!/-rc/) { | ||
printf "* %s\n",$0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put the asterisk behind the version tag
printf "* %s\n",$0 | |
printf "%s *\n",$0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll accept the suggestion, but also change the README at the same time, so I can't commit from this one 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like there should be a flag like "KERL_INCLUDE_RELEASE_CANDIDATES=yes" if you want rcs to be listed in your o/p? |
I'll add flag |
We keep the behaviour of only showing the highest version in each considered range (whether release candidates are requested or not)
As for the minimum versions (listed or supported) feel free to suggest changes to the variables that define those (instead of |
Here's some output (with release candidates) $ KERL_INCLUDE_RELEASE_CANDIDATES=yes ./kerl list releases
17.0-rc2
17.5.6.10
18.0-rc2
18.3.4.11
19.0-rc2
19.3.6.13
20.0-rc2
20.3.8.26
21.0-rc2
21.3.8.24
22.0-rc3
22.3.4.26
23.0-rc3
23.3.4.19
24.0-rc3 *
24.3.4.13 *
25.0-rc3 *
25.3.2.6 *
26.0-rc3 *
26.1.1 *
Run './kerl update releases' to update this list
Run './kerl list releases all' to view all available releases
Note: * means "currently supported" |
Here's some output (without release candidates) $ ./kerl list releases
17.5.6.10
18.3.4.11
19.3.6.13
20.3.8.26
21.3.8.24
22.3.4.26
23.3.4.19
24.3.4.13 *
25.3.2.6 *
26.1.1 *
Run './kerl update releases' to update this list
Run './kerl list releases all' to view all available releases
Note: * means "currently supported" |
Whatever the values that end up in those control variables (for older versions) I feel this is already a major improvement for what we have currently. |
Yes, no question - this is a lovely improvement. Thanks! |
We can leave at 17 for now I guess. |
Perfect stuff. @garazdawi, feel free to still comment on the final result, even if merged, as I might've not addressed all your concerns. In any case, I'm gonna move forward with other stuff I have prepared... |
lgtm! |
And as soon as it was merged it bit me 😄 I started a repo. with @starbelly that pulls |
Description
... as per the
README
's Erlang/OTP support policy, and the discussion below.Closes #459.