Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard to download a specific version of previous stable channel build of Dart SDK #18323

Closed
sethladd opened this issue Apr 19, 2014 · 10 comments
Closed

Comments

@sethladd
Copy link
Contributor

Adam and I needed to download Dart SDK 1.2 yesterday. We couldn't find a page that lists previous downloads.

@sethladd
Copy link
Contributor Author

Sharon, something to add to your doc tracking sheet?

@ricowind
Copy link
Contributor

This would indeed be very nice, I have several times found these by hand for people (just browsing the publicly available buckets) - let me know if you need anything from me

@Sfshaza
Copy link

Sfshaza commented Apr 29, 2014

This would be nice, but what, exactly, do we want to support?

First, it's very difficult, currently, to find the last stable release of a version. The directory structure does not reflect version numbering and, I gather, we sometimes use different build numbers for different platforms. For example, the last stable version of 1.2 might (I am told) use the build from 12345 for Mac OS X and the build from 12346 for Linux.

I would suggest that we implement a new directory structure and embed the release number right in the URL. Otherwise, creating and maintaining such a page would be non trivial.

Another suggestion, by Seth, is to include a JSON file in the build directory. I'm not sure exactly how this might work, but it could be auto-parsed to figure out what is what.

Finally, what is the purpose of creating and maintaining a "prior release" page? I suspect we don't want to support folks using older versions. Is it so they can test bugs? Is there another reason? I'd like to be clear on what problem it is solving.

@sethladd
Copy link
Contributor Author

The problems we can solve: we sometimes need to test old versions, or a new release has a bug and people need to downgrade. The downgrade issue has happened to many customers.

But you're right, we don't want to encourage developers living on old versions. Dartium has an expiration time anyway, so the Editor bundles have a built-in expiration.

@ricowind
Copy link
Contributor

  • a few relevant people

    First, it's very difficult, currently, to find the last stable release of a version.
    The directory structure does not reflect version numbering and, I gather, we
    sometimes use different build numbers for different platforms. For example, the last
    stable version of 1.2 might (I am told) use the build from 12345 for Mac OS X and
    the build from 12346 for Linux.
    That is not true - that may have been true in the old pre 1.0 days.

I would suggest that we implement a new directory structure and embed the release
number right in the URL. Otherwise, creating and maintaining such a page would be
non trivial.
We actually put a lot of thought into creating the current directory structure - which is consistent across channels (be, dev, stable), has a consistent one place location for generating those paths/names, has a clear semantic for what is released what is not, and is easily extendable if we want to add additional channels.
Creating such a page is actually not that hard
gsutil ls gs://dart-archive/channels/stable/release/*/VERSION | grep -v latest | xargs gsutil cat
gives you the info you need, creating a html page from that info seems straight forward

You can do the same thing for dev channel if you need to.

If we really need to we can add something like this to the promote script - but this should be doable from the app-engine scripts as well.


cc @mkustermann.
cc @kasperl.
cc @whesse.

@mkustermann
Copy link
Member

For example, the last stable version of 1.2 might (I am told) use the build from 12345 for Mac OS X and
the build from 12346 for Linux.

As rico said this is just wrong. Every release we do includes all components for all platforms and is based on exactly one SVN revision.

First, it's very difficult, currently, to find the last stable release of a version.

I disagree with "very difficult". It is definitely not user friendly, but it is not "very difficult". As rico demonstrated you can get the info you need with a one-liner. With a browser you can do a binary search on .../channel/*/VERSION.

Another suggestion, by Seth, is to include a JSON file in the build directory. I'm not sure exactly how this might work, but it
could be auto-parsed to figure out what is what.

Not sure what content that JSON file would have, but the [SVN revision] <-> [semantic version of sdk] mapping is already available in every sdk (and the editor zips include a dart-sdk folder):

$ cat dart-sdk/version
1.3.0-dev.7.12
$ cat dart-sdk/revision
34792

I would suggest that we implement a new directory structure and embed the release number right in the URL. Otherwise, creating and
maintaining such a page would be non trivial.

It's nice to have two different archived builds (on two different svn versions) even if someone forgot to update the SDK version file (in dart/tools/VERSION).

Main reason not to change the directory structure is that it would break things: old editor versions may not be able to update correctly, api.dartlang.org may stop working.

In effect: A lot of things are depending on that directory structure, so we should keep it stable and only change it if absolutely necessary.
We created that directory structure pre-1.0 and so far we never regretted it.

As rico said, the information itself is available, we would just need to surface this info (maybe on dartlang.org?).

I'd use symlinks with good names to our already existent "directory" names, but there are unfortunately no symlinks on google cloud storage :(

@sethladd
Copy link
Contributor Author

Lots of good discussion, thanks!

We'd like to generate the downloads page automatically from the client. The one-liner you gave:

gsutil ls gs://dart-archive/channels/stable/release/*/VERSION | grep -v latest | xargs gsutil cat

is really cool, but requires a command line and some utils on the path. Not everyone who builds the website has the utils.

Ideally, if there's a way to do it, a small script on the client does a fetch to some resource that lists all the versions and enough info for us to build links.

(We do this with benchmarks, for example. The benchmarks are described in a JSON file and we dynamically build the page. This way, the engineers can add a benchmark and we don't need to update the HTML on the site.)

It would be a really big help if the promote script put some machine readable file in some dependable location. We can then take it from there.

Thoughts?

@mkustermann
Copy link
Member

I could live with a gs://dart-archive/channels/{stable,dev}/releases.json containing metadata about all releases, something like:
[
  {
    "revision": "35068",
    "version" : "1.4.0-dev.2.2",
    "date" : "201404151157"
  },
  ...
]

As Seth says, the promote script could add an entry to this file every time we promote a new build.

@rico: WDYT?

@DartBot
Copy link

DartBot commented Apr 30, 2014

This comment was originally written by @financecoding


I like this. Eventually someone could build a nvm similar system for dart with this information.

@nicolasgarnier
Copy link
Contributor

This issue has been moved to Github as part of a migration. Please use the Issue on Github going forward: https://github.com/dart-lang/dartlang.org/issues


Added MovedToGithub label.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants