hiccup
hiccup copied to clipboard
weavejester
New version?
Hi @weavejester!
I'm going to add hiccup.core and hiccup2.core to babashka so people can use this in their scripts. I have copied the tests of these namespaces and they are all running, except those recently added by @kwrooijen regarding using a vector of keywords for a class name. I am using alpha2 which doesn't have the most recent commit yet. Is this worth another release?
#198 seems like a fairly serious issue if backward compatibility is expected to get out of alpha.
@weavejester , we'd love to see hiccup2.core published as it fixes many of our escaping woes and lots of companies have policies regarding alpha usage of packages in production.
I'll put this repo to the top of my todo list. I've been slowly modernizing all of my repositories, and I Hiccup seems a good candidate for what to work on next.
@weavejester Just a small note: I noticed you moved some libraries to a new org (dev.weavejester) but doing so can cause classpath conflicts (having the same old libraries + the new ones both on the classpath). Have you thought about how to address this? I moved a library to a different org once and I wouldn't want to do this again since it caused these kinds of problems and clojars doesn't support org redirection.
I was moving the libraries over as Clojars changed its policy around artifact group names, moving away from arbitrary group IDs and toward verifiable domain names. This seemed like a good idea, and for consistency I was going to release libraries under the new scheme. However, I hadn't considered how this might produce classpath conflicts.
I guess the ideal approach would be to talk to the Clojars folks about supporting group relocation.
Ah, I see there's an issue https://github.com/clojars/clojars-web/issues/801 for it already.
For existing libraries there isn't a need to change anything AFAIK.
I was trying to work out if there was something I could do about the libraries I've already transferred over to the new naming scheme.
Just in case you were considering moving more libraries, you just don't have to: you can keep publishing global/global.
I guess another alternative is to release dev.weavejester/hiccup, but to change the core namespace (say to weavejester.hiccup). The advantage would be that I could omit the legacy Hiccup 1 namespaces from the package without affecting existing projects. One of the key things holding a full release back was the interop between the two versions.
I understand where you're coming from, but from a personal standpoint I wouldn't like that as I've integrated hiccup in babashka and people rely on hiccup.core and hiccup2.core to be there, so I can't remove it. If I would then also include weavejester.hiccup to get future bugfixes/features, I'd include two versions and pay double the binary size/compile times.
Understood; I guess that means that Hiccup 2 is de facto stable anyway.
I've release Hiccup 2.0.0-RC1. If this turns out to have no issues, I'll release it again as 2.0.0.