Closed kevinresol closed 6 years ago
Yeah, I was a bit reluctant to merge, because it'll most likely break java, cs and quite possibly neko. But I think we should move ahead now and fix problems when people start complaining.
Personal opinion: Don't be afraid to break stuff. If you're too conservative, progress will be too slow. Let people complain when things break, or better yet, they might submit PRs to fix the broken parts.
It is nighttime here, and I will do the following in the next morning:
master
as old
pure
as master
master
I think this is the best way to preserve the history
Is this a good practice? Why not just merge to master?
You could use a git merge strategy as outlined here: https://stackoverflow.com/a/2763118/5872160
I know that, but we don't really want a "merge", but complete replacement.
e.g. we don't want old code, which is not part of pure
, to stay. For instance the Buffer
class in master is completely gone in pure
. If we "merge", it will stay.
Ok, after a shower my mind is back. Maybe it works, because merging should also bring in the "delete Buffer class" commit for example.
These have failing CI checks: https://github.com/haxetink/tink_io/pull/32 https://github.com/haxetink/tink_cli/pull/11 https://github.com/benmerckx/asys/pull/6 Is that ok? :)
From time to time people come and ask what
pure
is, because we usually recommend people to use it. Mostly because we have all new features & bug fixes on pure branch only now. I suppose we should merge pure and properly document what targets are supported. From my understanding they should include node and php (and sys with runloop?).Any objections? @back2dos @ciscoheat @gene-pavlovsky @benmerckx