Implement package candidate/published lifecycle

[hvr]

Give we're moving toward a scheme were packages are uploaded as candidates rather than published directly to the index (c.f. haskell/cabal#3931) we need to make sure that candidates don't pile up.

The usual workflow:

1. upload package candidate
2. inspect package candidate preview on hackage
3. repeat 1./2. until satisfied with outcome
4. publish candidate (either by Web UI or by cabal upload --publish)
5. delete candidate (either by Web UI or by CLI tooling which isn't widespread)

Step 5. is just busy work and gets easily forgotten

We could either address this in cabal by having it delete the candidate when using cabal upload --publish, but that wouldn't address the WebUI code-path.

So instead we should enforce the following invariant server-side:

• A package version shall never exist both as published and candidate.

Or put differently, a package version shall only be in one of 3 states:

• non-existent (initial state; -> {candidate, published(*)})
• candidate (-> {non-existent, published, candidate})
• published (final state)

(*) going straight from non-existent to published will be restricted in future for new package names (c.f. #481)

Expressed operationally, this could mean:

• when a package is published and there exists a candidate, said candidate shall be auto-deleted
• uploading a candidate version for an already published package version shall be rejected

[amigalemming]

What about packages that remain candidate forever? E.g. the uploader may notice that the package version was wrong and he will never go to publish the package with this version, but also forgets to delete the candidate?
Actually, my package candidates already pile up. The list of all candidate packages at Hackage is already huge. What about a garbage collection that can be initiated by an uploader?

[hvr]

@amigalemming Yes, that's a real issue;

For starters I was thinking about a page which lists all your packages which have candidates, with links to the "/candidates" pages;

basically a version of

http://hackage.haskell.org/packages/candidates/

intersected with http://hackage.haskell.org/user/HenningThielemann

and then we could have a "delete all candidates for this package" button on the http://hackage.haskell.org/package/HaRe/candidates/ page.

would that help?

[amigalemming]

On Wed, 2 Aug 2017, Herbert Valerio Riedel wrote: @amigalemming Yes, that's a real issue; For starters I was thinking about a page which lists all your packages which have candidates, with links to the "/candidates" pages; basically a version of http://hackage.haskell.org/packages/candidates/ intersected with http://hackage.haskell.org/user/HenningThielemann and then we could have a "delete all candidates for this package" button on the http://hackage.haskell.org/package/HaRe/candidates/ page. would that help?

Sure! The user page already lists all packages I maintain. It could add links to package candidates, as well. It could also add a button for deleting candidates of all packages I maintain. If it's easier I would also be happy with such functions in cabal-install. That is, using cabal-install I could write a small script to delete all candidates if there would be a cabal-install function for deleting a particular candidate.

[hvr]

@amigalemming I think I'll start prototyping the tool-based approach in https://github.com/hackage-trustees/hackage-cli

[gbaz]

@sitaochen what remains here or should it be closed?

[sitaochen]

Not sure if this is required but uploading a candidate version for an already published package version shall be rejected haven't been implemented yet.