New version?

[borkdude]

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?

[favila]

#198 seems like a fairly serious issue if backward compatibility is expected to get out of alpha.

[vincentjames501]

@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.

[weavejester]

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.

[borkdude]

@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.

[weavejester]

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.

[borkdude]

For existing libraries there isn't a need to change anything AFAIK.

[weavejester]

Ah, I see there's an issue clojars/clojars-web#801 for it already.

[weavejester]

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.

[borkdude]

Just in case you were considering moving more libraries, you just don't have to: you can keep publishing global/global.

[weavejester]

Yes, I know.

[weavejester]

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.

[borkdude]

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.

[weavejester]

Understood; I guess that means that Hiccup 2 is de facto stable anyway.

[weavejester]

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.

[borkdude]

@weavejester I upgraded hiccup in babashka and saw no issues, thanks!