v0.25.0 source archives claim v0.24.0

[bollwyvl]

System

• Version: 0.25.0
• Platform: source

Testcase

$ curl -LO https://github.com/mozilla/geckodriver/archive/v0.25.0.tar.gz
$ tar xaf v0.25.0.tar.gz
$ grep version geckodriver-0.25.0/Cargo.toml
version = "0.24.0"

Building and installing these...

cargo build --release --verbose
cargo install --bin geckodriver --root $PREFIX

...in turn yields binaries that report:

+ which geckodriver
$PREFIX/bin/geckodriver
+ geckodriver --version
geckodriver 0.24.0

c/f conda-forge/geckodriver-feedstock#9

[whimboo]

@andreastt looks like that Github automatically picks-up the current source of the release branch for the source archive. Given that we now mostly release from Taskcluster, the upstream sync hasn't been taken place, and as such the sources are still for 0.24.0.

Looks like we still have to sync as long as we have the releases page on Github. Can you please fix that?

[andreastt]

Hi @bollwyvl, thanks for filing an issue. I discuss this in https://lists.mozilla.org/pipermail/tools-marionette/2019-September/000112.html.

As the README points out, the canonical source code of geckodriver is in Mozilla’s central repository rather than on GitHub. As this was the first release of geckodriver made without involving any GitHub infrastructure, the source code is not available off the release branch.

If you instead check out the revision mentioned in the 0.25.0 changelog, bdb64cf16b68, this would give you a build that is 100% reproducible with those uploaded for 0.25.0.

I hope this helps!

[whimboo]

I don't think that we can close this issue. The source code package is explicitly listed on the release page, which will actually give users the impression that they got the 0.25.0 release. We will have to remove those links (not sure how), or update the code on the release branch.

[whimboo]

Course of action we might need here is:

1. Sync the code
2. move the 0.25.0 tag to the sync commit

Hopefully this will automatically update the 0.25.0 release page for the up-to-date source code.

As it looks like there is also no way to do a new release without source code.

[andreastt]

I don’t think it’s helpful to synchronise the code to the release branch for two reasons: it wouldn’t be an accurate representation of bdb64cf16b68 because it would necessitate local changes to relative crate dependencies making it irreproducible, and it’s not worth the time investment considered we are likely to decommission this GitHub project before the 1.0 release.

[bollwyvl]

Thanks for looking into this!

So would...

https://hg.mozilla.org/mozilla-central/archive/bdb64cf16b68c4a7212ba16aef425bce66d8f4ca.tar.gz/testing/

...be an equivalent (superset) to the previously-github-released source? I found i couldn't just pull /testing/geckodriver because of the aforementioned local crate dependencies. It appears to build and generate a geckodriver 0.25.0 binary, so that's a strong mark in its favor!

[whimboo]

Note that people and tools might still grab those sources for custom builds. They all would end-up with 0.24.0 for any future release as shipped via github. It might take a while for them to notice, and also might get errorneous issue reports. :(

[ei-grad]

Official ArchLinux package is affected by this issue :(.

[andreastt]

@ei-grad Please report a bug upstream with ArchLinux.

[whimboo]

Marking as dupe of issue #1695