Re-release Markup.ml 1.0.0

[aantron]

I'd like to amend the Markup 1.0.0 release from last week (#17431) with a new breaking change. cc @dmbaturin.

Changelog:

Breaking

• Include tag attributes in `Misnested_tag errors, to assist in error recovery (Report attributes with `Misnested_tag aantron/markup.ml#55, Albert Peschar).
• Delete type content_signal (Eliminate subtyping around type signal aantron/markup.ml#59).

Bugs fixed

• Parser hangs on <rb> and other ruby annotation tags (Added failing test for <rb> tag without surrounding <ruby> aantron/markup.ml#56, reported Julien Sagot).
• Preserve the original doctype when outputting HTML (aantron/markup.ml@b4b59ae, reported Daniil Baturin).
• Pretty-printer: emit newline after doctype (Add a newline after the doctype declaration aantron/markup.ml#58, reported Daniil Baturin).

[camelus]

Commit: bed0617

A pull request by opam-seasoned @aantron.

☀️ All lint checks passed bed0617

• These packages passed lint tests: markup.1.0.0-1, markup.1.0.0

---

🌤️ Installability check (+0)

• these releases are not installable anymore (1): markup.1.0.0
• new installable packages (1): markup.1.0.0-1

[dmbaturin]

@aantron Your opam file has a wrong checksum.

You have this:

url {
  src: "https://github.com/aantron/markup.ml/archive/1.0.0.tar.gz"
  checksum: "md5=d41d8cd98f00b204e9800998ecf8427e"
}

But actual tarball has:

$  wget https://github.com/aantron/markup.ml/archive/1.0.0.tar.gz
$ md5sum ./1.0.0.tar.gz 
d9964f196850af5507b66b7a141bff11  ./1.0.0.tar.gz

[aantron]

@dmbaturin Thanks, fixed. Was a firewall issue.

[mseri]

Do we have to re-release? There have been a lot of complaints about mutability of releases, is there no other option in this case?

I will also ping @kit-ty-kate for an opinion

[avsm]

If this is re-released, please bump the epoch (so markup.1.0.0-1) to indicate the checksum has changed for a known reason. This seems like a reasonable convention in the event that upstream really wants a re-release.

[aantron]

I changed the version number to 1.0.0-1.

I still think this is unnecessary in this particular case, as a fast merge is likely to avoid causing problems for downstream projects.

[avsm]

I still think this is unnecessary in this particular case, as a fast merge is likely to avoid causing problems

Unfortunately, we can't predict when the people using opam-repository take their snapshots for their own deployments, so this hasn't been true in the past. (I caused great drama in the Tezos downstream opam-repo with a re-release of uri last year, for instance).

[dmbaturin]

How should I specify that version as a dependency? Will markup { >= 1.0.0-1 } work as expected?

[avsm]

Yes, if you add quotes around the version.

[kit-ty-kate]

Since it is already changing versions, could it be 1.1.0 or 2.0.0 to reflect the API break?
Also the tag changed. Could you add available: false to the markup.1.0.0 package?

[aantron]

I created a markup.1.0.0-1 directory with the new opam file, reverted the previous markup.1.0.0/opam, and added available: false to it.

[mseri]

Thanks!

[aantron]

Thank you!