I'm going to close #19 with support of 2.10+ releases (2.10.0 and so on). This issue tracks additional work to support pre-releases like 2.10.0-rc1. I splitted the tasks, because I'm not sure about the best API for pre-releases.
Or with exact version: tarantool-version: '2.10.0-rc1'.
Okay. What if I want latest 2.10.0pre-release? tarantool-version: '2.10.0'? 2.10.0-rc1 is logically before 2.10.0, will not such tarantool-version confusing? OTOH, it is valid prefix and surely implements at least some of 2.10 feature set functionality. I'm not sure how we should interpret 2.10.0 in this context.
Next question. What if we want latest release or (if there are no release) latest pre-release of 2.10 feature set? We should be able to enable release and pre-release repositories both:
steps:
- uses: actions/checkout@v2
- uses: tarantool/setup-tarantool@v1
with:
tarantool-version: '2.10'
<do not know how to name it>: ['release', 'pre-release']
We can also add 'live' into the list of possible values (for 1.10): so a user may have the ['1.10', '2.8', '2.10'] matrix of tarantool versions and acquire a latest available build this way:
steps:
- uses: actions/checkout@v2
- uses: tarantool/setup-tarantool@v1
with:
tarantool-version: ${{ matrix.tarantool }}
<do not know how to name it>: ['release', 'pre-release', 'live']
What else to consider:
The cache key is matched as a prefix (see also https://github.com/github/docs/issues/14145). 1.10 and 2.8 has the git hash in versions, but 2.10.0-beta1 is just 2.10.0-beta1, so it may clash with, say, 2.10.0-beta10. I guess we should add something to the end of the cache key.
I need to think around use cases and possible APIs here.
I'm going to close #19 with support of 2.10+ releases (2.10.0 and so on). This issue tracks additional work to support pre-releases like 2.10.0-rc1. I splitted the tasks, because I'm not sure about the best API for pre-releases.
What comes into the head first:
Or with exact version:
tarantool-version: '2.10.0-rc1'
.Okay. What if I want latest
2.10.0
pre-release?tarantool-version: '2.10.0'
?2.10.0-rc1
is logically before2.10.0
, will not suchtarantool-version
confusing? OTOH, it is valid prefix and surely implements at least some of 2.10 feature set functionality. I'm not sure how we should interpret2.10.0
in this context.Next question. What if we want latest release or (if there are no release) latest pre-release of 2.10 feature set? We should be able to enable release and pre-release repositories both:
We can also add
'live'
into the list of possible values (for 1.10): so a user may have the['1.10', '2.8', '2.10']
matrix of tarantool versions and acquire a latest available build this way:What else to consider:
I need to think around use cases and possible APIs here.