Make first alpha release for v0.15.0#4251
Make first alpha release for v0.15.0#4251JordanMartinez merged 6 commits intopurescript:masterfrom JordanMartinez:make-0.15.0-rc1
Conversation
This reverts commit 726a95d.
|
Once #4241 is merged, I think this release should be made. |
|
Really? Seems like we have some more breaking changes that have just been recently proposed. Do we want to push them for another major release? Or do we use the term ‘release candidate’ here to mean something other than ‘this build is a candidate for being the final release, if no issues arise during testing’? |
|
Ah, sorry! Let me clarify. Calling this a 'release candidate' is just using the wrong term. It's more like a 'beta release'. Making a "not ready for production use yet" release means I can start testing ES modules migration PRs that are being submitted to the core repos. Since most repos already use In other words, I fully expect to merge more breaking changes PRs before we make a final |
|
We need an ES-modules-compliant version of the compiler to be available so we can start making 0.15 changes across the purescript, purescript-contrib, purescript-node, and purescript-web organizations. However, they certainly don't need to be named "release candidates" and carry the |
|
Oh good, thanks for explaining guys. I have no objection whatsoever to an alpha or beta release at this time, and given past precedent, I'm even mostly okay with calling it an RC... but the suggestion to actually use something like |
|
Let's call it "alpha". I think using more accurate terminology prevents cases of confusion like this 😄. |
JordanMartinez
changed the title
app/Version.hs
Outdated
| -- set this to an empty string. | ||
| prerelease :: String | ||
| prerelease = "-rc1" | ||
| prerelease = "-alpha1" |
There was a problem hiding this comment.
I don't know what convention we typically follow, but I'm used to seeing -alpha.1 and -rc.1 (with the dot)
There was a problem hiding this comment.
🤷♂️ If we include the ., then Version.parseVersion (assuming I'm reading it right) will list the two values separately. But the general question is, "Does it matter?"
There was a problem hiding this comment.
Practically, I think it only matters if we have more than 9 alpha releases, in which case per (my reading of) the SemVer spec, -alpha10 will sort before -alpha2, but -alpha.10 would sort after -alpha.2.
There was a problem hiding this comment.
(Our history on this seems less than fully consistent.)
There was a problem hiding this comment.
Ok, dot it is!
There was a problem hiding this comment.
There was a problem hiding this comment.
Oops, guess you can't do a dot in .cabal. In that case I'm happy with alpha-1.
3 participants
Description of the change
This follows the approach done in #3976. In #3933, we dropped
package.yamlfile. Runningstack buildand then callingpurs --versionon the produced binary prints this output:I'm not sure when we want to make the first release candidate (as there may be additional work to do before such a release), but once this PR is merged, we'd make a new GH release by creating a tag for
v0.15.0-rc1and checking the 'Is prelease' checkbox.Checklist: