Support Racket 5.3.2 or newer
greghendershott opened this issue · comments
[Split out as requested from #1]
This would make it easer for rackjure, which currently supports Racket 5.3.2 or newer, to use this package.
In my experience with rackjure's threading.rkt, nothing requires any special treatment for Rackets as old as 5.3.2. It is straightforward to add builds to the .travis.yml and verify that the tests pass.
I'm not suggesting making any non-trivial effort to support older Rackets. And if at some point it were to become awkward to support an older Racket, I think it would be totally reasonable to drop support. Meanwhile, I'm suggesting just "assume compatible until demonstrated otherwise".
I've added a compatibility branch that supports everything back to 5.3.2, compatibility-5.3.2-to-6.1. I apparently inadvertently uncovered a bug in syntax/parse regarding #:literals and the underscore that existed until 6.1.1, so this branch supports versions through 6.1.
Thanks for looking into this! It's great to know that #:literals and _ is the only issue.
Is there a reasonable work-around for that?
Why I ask:
- 6.1 isn't very old; that might still be the version from some Linux package managers.
- I don't understand how I'd make use of such a branch, in the rackjure package. If someone is using an older Racket, and they
raco pkg update rackjure, it would be nice for that not to break if possible.
I added version exceptions in the package catalog for Racket 5.3.2—6.1, so that branch should be used as the package source automatically on those Racket distributions.
Oh. Fancy. :)
Seriously, I've never tried that and forgot all about that option. Sounds great. (I'm guessing you're not too concerned about keeping the branches in sync, because you expect this to settle down soon and not have many more commits.)
Thanks again!
Hmm. I'm not so sure about this approach using dual branches and version exceptions: Most of my builds are failing, for two reasons related to this approach:
- It seems like it is tricky to keep the branches in sync. The compat branch is missing efa04ca, causing builds 5.3.6 through 6.1 to fail. You could update the compat branch with that, now. But (a) this could happen again, and (b) ....
- Racket versions 5.3.5 and earlier don't seem to understand version exceptions, causing the 5.3.2 and 5.3.5 builds to fail.
Would it really be to bad to use the inline ~literal that the compat code uses, even for newer Racket versions? So that there's just the one, master branch, and no version exceptions?
You're right about failing to cherry-pick efa04ca—that's my bad, and I've fixed that now—but ultimately I'm reluctant to make it a policy to avoid version exceptions. As far as I'm concerned, this is just a perfect exposition of how broken the package system is.
Using ~literal wouldn't be so bad, you're right. I'd consider it if it weren't for the fact that I plan to break compatibility with 5.3.2 eventually, anyway. Part of the point of versioning is to be able to drop support for older versions, but still have those packages function properly. I adopt a policy of never breaking versions of my packages, but if you want all the new goodies, you'll need to upgrade.
Avoiding version exceptions entirely sets some potentially poor precedent that would mean every single version of this package would need to maintain compatibility with every single Racket version that supports the package system. I'd never be able to use new features of syntax/parse, for example, if they were ever introduced. This is a very bad idea. One could just introduce version exceptions later, if they ever became absolutely necessary, except for...
Racket versions 5.3.5 and earlier don't seem to understand version exceptions, causing the 5.3.2 and 5.3.5 builds to fail.
This is annoying. I can't come up with a solution to this, and I don't really plan to. I would understand if you'd like to maintain rackjure compatibility with Racket 5.3.2, but it's not actually necessary for a new package like this one, and I'd rather take the insignificant hit and not shoot myself in the foot and stunt myself when growing this package in the future.
Package systems need versioning. "Version exceptions" do not count, but they are a crude hack to attempt to address the problem in the absence of a real versioning mechanism. This issue is an early manifestation of the problem—I expect those manifestations to grow more frequent and more problematic as the Racket ecosystem matures if a real versioning system is not introduced.
In fairness, the new package system didn't debut until around 5.3.6. I'm kind of amazed it works at all, for 5.3.5 and earlier.
Of course you could argue that shows just how freaking old those versions are, and why support them.
Maybe I've spent too much time with languages that have evolved over time, but: I don't think it's too big a sacrifice to avoid a newer construct when it's more of a local convenience. (I realize "local convenience" is in the eye of the beholder.) I haven't minded doing that in Racket so far.
For me, the bigger annoyance would be juggling multiple release branches. But that's me. You'll be maintaining this and you think it's worth it. Of course that's your call.
I suppose I could drop 5.3.5 and earlier from rackjure. Two years ago, I think 5.3.5 was still in the Debian packages. 5.3.2 was already old, but no big effort (I felt) to support, so why not. But in late 2015, I could drop those.
Drawing the line at 5.3.6 would mean at least the version exception mechanism is available.
So it sounds like that's the way to go.
I want to thank you again for proposing that there be one threading package for everyone to use, and taking the lead to make it happen! No good deed goes unpunished. :) Seriously, I hope you're not regretting it too much. Thanks!!
In fairness, the new package system didn't debut until around 5.3.6. I'm kind of amazed it works at all, for 5.3.5 and earlier.
Of course you could argue that shows just how freaking old those versions are, and why support them.
Both fair points. I'm certainly not too broken up about not having support for 5.3.2. 😉
For me, the bigger annoyance would be juggling multiple release branches. But that's me. You'll be maintaining this and you think it's worth it. Of course that's your call.
I tend to just tag old releases, add a version exception, and leave them alone. As a downside, you don't get new features on old versions, but I consider this a small loss given that upgrading to a new Racket version is cheap.
I suppose I could drop 5.3.5 and earlier from rackjure. Two years ago, I think 5.3.5 was still in the Debian packages. 5.3.2 was already old, but no big effort (I felt) to support, so why not. But in late 2015, I could drop those.
Drawing the line at 5.3.6 would mean at least the version exception mechanism is available.
So it sounds like that's the way to go.
If you're willing to drop support for versions below 5.3.6, I'd be happy to work to support them. Thank you for your helpful work to share the knowledge you already learned from rackjure—it's certainly nice to not need to repeat those same mistakes.