Crystal 0.24.2 #5642
Crystal 0.24.2 #5642
Conversation
* Fix docs directory in gitignore.ecr (renamed in #4937)
Debug::DWARF::LineNumbers would skip the program statement when it contained a single entry, because of a wrong assumption of the sequence unit_length entry, which doesn't account for the unit length space in the standard, and was overlooked in checking whether the sequence had any program statement, or not.
…L::Context::Server Fixes #5266 x509 certificates have a purpose associated to them. Clients should verify that the server's certificate is intended to be used in a server, and servers should check the client's certificate is intended to be used for clients. Crystal was mistakingly checking those mixed up. See https://wiki.openssl.org/index.php?title=Manual:X509(1)&oldid=1797#CERTIFICATE_EXTENSIONS See https://tools.ietf.org/html/rfc5280#section-4.2.1.3
matiasgarciaisaia
force-pushed
the
release/0.24
branch
from
bb7e1ec
to
1445529
Compare
|
Shouldn't this be PRing the changelog into |
|
All the commits in The changelog edits should be in your fork, being PRed into |
Move setup from .travis.yml to /bin/ci
Build master, release and ci branches Build tags
Make travis build ci branches
run dist only after test on all platforms run. split workflows for: 1. test all platforms 2. tagged releases 3. nightly releases 4. maintenance releases (specific branch build per commit)
Remove package iteration args Tidy up dist_docker args
|
Why this release contains only cherry-picked commits/PRs, instead (like it was before) including all since the previous release? |
|
The idea is to have point-releases as bugfix-only. We would have wanted this to be released shortly after 0.24.1, but we didn't do that on time. SemVer allows us to do whatever we want before 1.0, but we should at some point start to practice following it as if we were 1.0. So 0.24.2 would be a bugfix release - no new features. There are also some specific reasons to have a new 0.24.2 release before releasing 0.25 with all the new features that are ready (namely, an issue with libgc that prevents us from building 32 bits on Docker). So we can expect 0.25 to come "soon" after 0.24.2 (for really relaxed values of "soon"). |
|
Next time, can we agree to commit everything to master and then cherry-pick those commits onto branches? |
|
@Sija it's more a manner on how to to implement git-flow. If when more that one version is been developed at the same time (like a maintenance release branch vs master) at manas we find easier to track to fix things in one place an then merge into master once release is done (or even regularly). The merge commit serves as the intention to include all the fixes. We found cherrypicking harder to track and to check. For sure the merge commit can get wrong, but at least the intention is clear and serves as a point of discussion. We usually work using a slight modification of http://nvie.com/posts/a-successful-git-branching-model/ . |
|
IME git-flow is good for a company internal workflow but falls apart if applied without modifications in a OSS context, mainly due awareness issues but also longer development cycles. |
|
Nah, git flow is just terrible in any context. Please do not attempt to apply it to crystal. Especially as back porting fixes branches like this should be super rare (only for security bugs). |
|
|
See #5358 for context on why we have this PR going :)
We're still missing a couple of changes on the release process before actually releasing this - please don't merge yet.