Put a date in the stackage URL

[cies]

The current Stackage URL does not indicate when it was build, and that makes it difficult to quickly find how old the snapshot is that a particular project is/was known to build with.

On top of that I think the current line is very long:

remote-repo: stackage-e8c0534113aee304c02889411e2a38c25373ede0:http://www.stackage.org/stackage/e8c0534113aee304c02889411e2a38c25373ede0

Would something shorter and more descriptive not be possible?

remote-repo: stackage-20141121-5373ede0:http://www.stackage.org/stackage/20141121-5373ede0

Currently it is a hex code; maybe a base64 (possibly without special chars, so base62) could be used to make collisions even more impossible or the URL more short. Given that the date is in the URL collisions are already extremely unlikely.

Last question; could http://www.stackage.org/stackage/... be changed to https://stackage.org/snapshot/...? [https, no www as it is not html, snapshot as that's what it is]

[chrisdone]

One idea we discussed in the past was just having the date for the hash, yeah. DATE-UUID where the UUID is just a monotonically increasing number for that day may be possible.

It occurs to me that the /stackage/ route is an artifact from before we decided to call them ‘snapshots’, we could rename it to /snapshot and 301 redirect the old one.

@snoyberg Thoughts?

[snoyberg]

I generally agree but don't have time today to answer. Let's discuss next
week
On Fri, Nov 21, 2014 at 1:24 PM Chris Done notifications@github.com wrote:

One idea we discussed in the past was just having the date for the hash,
yeah. DATE-UUID where the UUID is just a monotonically increasing number
for that day may be possible.

It occurs to me that the /stackage/ route is an artifact from before we
decided to call them ‘snapshots’, we could rename it to /snapshot and 301
redirect the old one.

@snoyberg https://github.com/snoyberg Thoughts?

—
Reply to this email directly or view it on GitHub
#37 (comment).

[snoyberg]

I found some time after all. Thoughts:

1. Agreed on changing to /snapshot/
2. Agreed on 301 redirects for any current links
3. We'll still keep hashes as the internal representation of a snapshot (to disallow multiple uploads of the same snapshot).
4. Instead of just DATE-UUID, what about letting the uploader request a name? I'd like to name mine things like 2014-11-20-ghc78. We can use a monotonically increasing number at the end of disambiguation if necessary.
5. For migration purposes: we'll just use the hash as the unique name.

Sound reasonable?

[chrisdone]

Sounds reasonable to me.

[cies]

Love you guys. :)

[snoyberg]

OK, I have to call it here till next week, but I want to backpedal on what I said above. Maybe there isn't a point to the hash-based idents at all, and instead we'll just let uploaders request a name when uploading and use that. The only downside is that we can't stop double-upload, which isn't a big deal in reality.

[cies]

If you add hours and second to the date, then double uploads are practically impossible. Adding a username in the URL (like with github and launchpad PPAs) helps as well.

[snoyberg]

@chrisdone I've implemented these changes. For various uninteresting reasons I had to go with my original approach for the data model. The changes are on the 37-nicer-urls branch. Can you check it out before I release to production?

[snoyberg]

I've deployed these changes to production. The current URLs are migrated from the old titles, so they're not completely consistent. Snapshots released from now on will have proper, consistent snapshot names, like 2014-11-24-76-exc. Please give it a shot and see how it works.

And thanks for bringing this up @cies, I think it makes it much nicer to use.

[snoyberg]

Closing this issue as resolved, if there's still a problem please reopen or start a new issue.