[dart-announce] Presenting Dart channels

[Rico Wind]

Over the last few weeks we have been introducing the new channel based setup for providing users with updates to their editor and sdk.

We currently supply two different channels, dev and stable. For the last few weeks we have been updating these concurrently, so most of the time both channels have been getting basically the same bits (modulo a difference in the _rREVISION variable in the version).

All existing users that has been with us from pre 1.0 days have been automatically updated to the dev channel. 

If you go to the dartlang webpage the default download links are now to the stable channel, links to use the dev channel is in the text below. We are insanely thankful for all the feedback from early adopters, and we hope that a good chunk of you will stay on dev channel to give us early feedback and bugs before that hits stable channel moving forward - in return for getting early access to bug fixes and features :-).

There may be some variations in our schedule, but we would like to cut a new minor version of Dart approximately every 6 weeks. Dev channel will be used to stabilize these releases, so it will be full dumps of reasonable bleeding edge versions for a few weeks, followed by a number of patch releases until we have something that is completely stable. We will try our best to not break anybody or introduce new bugs, but dev channel will be more unstable by nature. Stable channel will receive only critical and security bug fixes between minor versions.

The first new full release (i.e., the first 1.1 release) will be arriving on dev channel in the coming weeks. If you are currently on dev channel and wish to switch, you need to go download the stable version from the webpage. 

Packages are released independently of the channels, i.e., you will normally be able to upgrade to new versions of packages when authors upload one, even if you are on stable channel.

Cheers,

Rico

--
For more news and information, visit http://news.dartlang.org/
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

[tomaszkubacki]

Links to stable and dev channel releases are both provided on this https://www.dartlang.org/tools/editor/ page for those (like me) of who are a bit lost :)

eg. for linux x64

http://storage.googleapis.com/dart-archive/channels/stable/release/latest/editor/darteditor-linux-x64.zip

vs

http://storage.googleapis.com/dart-archive/channels/dev/release/latest/editor/darteditor-linux-x64.zip

[Alexandre Ardhuin]

Is there still a place to retrieve continuous builds from trunk ? Or should we build from the sources ?

Cheers,

Alexandre

2013/11/20 tomaszkubacki <tomasz....@gmail.com>

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Rico Wind]

So dev channel releases are basically coming of trunk (when we promote these). You can still download the bits directly from trunk builds if you want to, but there may very well be issues with these, so this is not "supported" like the regular channels. You can get the raw, unsigned bits here:

http://gsdview.appspot.com/dart-archive/channels/dev/raw/latest/

Cheers,

Rico

[Alexandre Ardhuin]

Thanks !

Alexandre

2013/11/20 Rico Wind <ri...@google.com>

[Günter Zöchbauer]

Great info Rico, thank you very much.

1.0.0.8 30352 :)

Courious if some of the blocking bugs are already fixed.

FYI The path in download_contentshell.sh doesn't work.

NP. Found appropriate content_shell download in http://gsdview.appspot.com/dart-archive/channels/dev/raw/latest/dartium/ .

[Günter Zöchbauer]

I guess packages will not be available in dev or continuous build versions?

On Wednesday, November 20, 2013 11:37:16 AM UTC+1, Rico Wind wrote:

[Rico Wind]

On Wed, Nov 20, 2013 at 12:24 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Great info Rico, thank you very much.

1.0.0.8 30352 :)

Courious if some of the blocking bugs are already fixed.

If you are that curious, just look at the log :-)

svn log --limit 5 http://dart.googlecode.com/svn/trunk

 

As I said before, just because something has been pushed over to trunk it does not necessarily mean that it will be released on dev, we have additional checks (that said, 1.0.0.7 has just been promoted on dev, and 1.0.0.8 is just a test update)

Cheers,

Rico

FYI The path in download_contentshell.sh doesn't work.

NP. Found appropriate content_shell download

+kustermann for this 

[Rico Wind]

On Wed, Nov 20, 2013 at 12:41 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

I guess packages will not be available in dev or continuous build versions?

Packages are released independently of the sdk and editor. If package owners wanted to create a dev version I guess they could do that. +siggi,+bob for details

[Martin Kustermann]

Hi Günter,

thank you for your mail.

> FYI The path in download_contentshell.sh doesn't work.

> NP. Found appropriate content_shell download 

> in http://gsdview.appspot.com/dart-archive/channels/dev/raw/latest/dartium/ .

Could you please tell me what path is in your download_contentshell.sh?

Did you pick a darteditor from a .../raw/.... instead of a .../release/.... bucket?

Thanks,

Martin

[Günter Zöchbauer]

Hi Martin,

yes raw as in the mail from Rico.

I downloaded Darteditor from http://gsdview.appspot.com/dart-archive/channels/dev/raw/latest/editor/darteditor-linux-x64.zip

The path in download_contentshell.sh is

http://storage.googleapis.com/dart-archive/channels/dev/release/30352/dartium/content_shell-linux-x64-release.zip

which shows

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>

<Code>NoSuchKey</Code>

<Message>The specified key does not exist.</Message>

</Error>

[Martin Kustermann]

Thanks Günter,

that explains it. So your editor was build and archived on our buildbots, but it hasn't been released. The two download scripts we put in 'dart/chromium' will only work for released builds.

If you want to get the latest dev/stable build of the editor, please use the links provided on dartlang.org, such as:

 - http://dartlang.org/editor/update/channels/dev/latest/editor/darteditor-linux-x64.zip

 - http://dartlang.org/editor/update/channels/stable/latest/editor/darteditor-linux-x64.zip

(or a revision instead of .../latest/...)

These will redirect you to the correct google cloud storage locations.

[Günter Zöchbauer]

I thought so.

I'm very happy to have a source for continuous builds.

Don't care much about the not working download script.

I posted it as feedback so that others don't waste time investigate.

[Siggi Cherem]

On Wed, Nov 20, 2013 at 3:45 AM, Rico Wind <ri...@google.com> wrote:

On Wed, Nov 20, 2013 at 12:41 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

I guess packages will not be available in dev or continuous build versions?

Packages are released independently of the sdk and editor. If package owners wanted to create a dev version I guess they could do that. +siggi,+bob for details

Exactly - the idea is that packages will be released independently and could potentially have a dev version. Since packages versions can be specified explicitly in pubspecs, there is more liberty in how packages are updated. If we find that something needs to be updated (for example, an important bug fix), we can upload a new version of the package without having to wait for the next dev or stable release.

We are also thinking about having special versions, such as "1.1.0-dev", to distinguish stable vs dev releases of a package as well. Pub might be able to filter out some of these versions, so you don't accidentally get it on a pub upgrade unless you explicitly ask for it.

[Bob Nystrom]

On Wed, Nov 20, 2013 at 1:24 PM, Siggi Cherem <sig...@google.com> wrote:

Pub might be able to filter out some of these versions, so you don't accidentally get it on a pub upgrade unless you explicitly ask for it.

This is now supported in pub. When selecting the "best" version of a dependency, it will sort dev versions (anything with a "-" suffix) after all stable versions. So, if your dependency has these versions:

2.0.0-dev.1

1.5.0

1.3.0

Pub will try to pick 1.5.0 then (if that fails) 1.3.0 and only if those both don't work will it pick 2.0.0-dev.1.

Cheers!

- bob

[Günter Zöchbauer]

Can it be defined somehow that pub should pick the most current no matter if -xxx or not?

[Bob Nystrom]

On Thu, Nov 21, 2013 at 10:10 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Can it be defined somehow that pub should pick the most current no matter if -xxx or not?

Yes, if you want to explicitly opt into a dev release, all you need to do is specify a version constraint that excludes the other stable releases. For example, let's say you want to use the latest unstable version of foo, and it currently has these versions:

• 1.0.0
  
• 1.5.0
  
• 2.0.0
  
• 2.1.0-rc.1
  
• 2.1.0-rc.2

If you add a dependency like:

dependencies:

  foo: >2.0.0

Then the only versions that match it are the two unstable ones, so it will have to pick one of those. The simplest way to constrain a dependency to an unstable one is just a single version constraint:

dependencies:

  foo: 2.1.0-rc.1

Here, obviously only 2.1.0-rc.1 matches, so that's what pub will pick. Using single version constraints like this is a good idea for unstable versions since (as "unstable" implies) any two unstable versions may be incompatible with each other. If you know you do want an unstable version, you probably know exactly which one you want, so it makes sense to constrain to just that one.

Cheers!

- bob

[Günter Zöchbauer]

Thank you for clarification.

I don't like that solution very much.

dependencies:

  foo: >2.0.0

If there exists a 2.0.1 and then is a 2.0.2 published pub will not upgrade.

IMHO there should be an option in pubspec.yaml to opt for conservative or progressive.

I just want the newest available package until something breaks.

Then I limit a dependency to the second latest version until the issue is fixed.

Now I have continually to check manually each dependency if a newer version is available and update the pubspec.yaml.

I think that this will especially get labor-intensive because the official Dart packages must be taken into account too because they are not closely bound to the Editor version anymore.

In Dart all things are new and emerging and changing fast and continually

and usually few things will work and each update will be a great improvement everyone is already waiting for. 

pub upgrade should at least print a summary what was updated and for which dependency a newer version is available.

Currently it prints 'Dependencies upgraded!' even if it did nothing.

Günter

On Thu, Nov 21, 2013 at 7:29 PM, Bob Nystrom <rnys...@google.com> wrote:

dependencies:

  foo: >2.0.0

Mit freundlichen Grüßen

Günter Zöchbauer
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

[John Messerly]

On Thu, Nov 21, 2013 at 11:06 AM, Günter Zöchbauer <gue...@gzoechbauer.com> wrote:

Thank you for clarification.

I don't like that solution very much.

dependencies:

  foo: >2.0.0

If there exists a 2.0.1 and then is a 2.0.2 published pub will not upgrade.

IMHO there should be an option in pubspec.yaml to opt for conservative or progressive.

I just want the newest available package until something breaks.

Here's a reason you might not want to use a "-dev" version: they can have breaking changes between releases. If we have:

polymer 0.10.0-dev

polymer 0.10.0-dev1

polymer 0.10.0-dev2

... each of those releases can break stuff relative to the previous release. If you're always trying to "get latest" using pub upgrade, you might upgrade to -dev, be really happy with the new features, then really sad when they are changed or removed and you have to update your code. A lot of users aren't happy with such frequent breaking changes. For that reason, I'm not sure we'll even publish "-dev" versions unless we want feedback on specific new APIs we're working on.

 

Then I limit a dependency to the second latest version until the issue is fixed.

Now I have continually to check manually each dependency if a newer version is available and update the pubspec.yaml.

I think that this will especially get labor-intensive because the official Dart packages must be taken into account too because they are not closely bound to the Editor version anymore.

In Dart all things are new and emerging and changing fast and continually

and usually few things will work and each update will be a great improvement everyone is already waiting for. 

pub upgrade should at least print a summary what was updated and for which dependency a newer version is available.

Currently it prints 'Dependencies upgraded!' even if it did nothing.

Günter

On Thu, Nov 21, 2013 at 7:29 PM, Bob Nystrom <rnys...@google.com> wrote:

dependencies:

  foo: >2.0.0

Mit freundlichen Grüßen

Günter Zöchbauer
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

--

[Bob Nystrom]

On Thu, Nov 21, 2013 at 11:06 AM, Günter Zöchbauer <gue...@gzoechbauer.com> wrote:

dependencies:

  foo: >2.0.0

If there exists a 2.0.1 and then is a 2.0.2 published pub will not upgrade.

No, if you run pub upgrade here, it will upgrade to 2.0.2. What it won't do is upgrade to 2.0.2-scary if 2.0.1 exists.

This change only makes pub conservative about unstable versions, not all versions. (It wouldn't be a very useful "upgrade" command if it always tried to downgrade. :) )

I just want the newest available package until something breaks. 

Then I limit a dependency to the second latest version until the issue is fixed.

Right, so what you want is the latest non-broken version. That almost always means the most recent stable release, which is what pub will give you. What it won't do is give you a release that has been specifically tagged as unstable (unless you explicitly ask for it).

 

Now I have continually to check manually each dependency if a newer version is available and update the pubspec.yaml.

You'll only have to do this if you want to track development versions of packages. If you really are riding on the bleeding edge like that, you will probably have to manually change things every time a new version comes out anyway: that's what an unstable version number implies.

 

I think that this will especially get labor-intensive because the official Dart packages must be taken into account too because they are not closely bound to the Editor version anymore.
In Dart all things are new and emerging and changing fast and continually
and usually few things will work and each update will be a great improvement everyone is already waiting for. 

This is certainly less true for the Dart SDK now that we have reached 1.0. Stable releases of the SDK should be fully backwards compatible with all previous releases down to 1.0.

For our packages, it depends entirely on the package. Some are stable (i.e.: path) and some are not (i.e. barback). In either case, the only time you won't get the latest version of the package is if the maintainer explicitly marks that version as unstable (by giving it a "-" suffix). If they do that, they are telling you "caution! breaks things!" so I think it makes sense to not automatically put that version in front of end users who didn't specifically request it.

Here's another way to think about it: when a package's version number is < 1.0.0, it's considered "unstable". Any version that starts with "0." can be completely incompatible with a previous version. All bets are off.

This is useful, because it lets package developers quickly iterate on their APIs and try new things. They can still get feedback from users by publishing their package even though it's unstable. This is really important for getting to a good API.

But once a package hits 1.0.0, that party is over. Any new version after that must be compatible with previous versions (until you hit 2.0.0). That makes it much harder to try out new things before committing to supporting them forever.

Pre-release versions, version numbers with a "-" suffix, basically let a package temporarily go back into "0.x.x" mode. That lets you put out versions without committing to supporting them so that early adopters can give you feedback. But it really does mean your package is temporarily back to its unstable "0.x.x" days. That's not something your average user wants.

Cheers!

- bob

[Günter Zöchbauer]

Hi Bob,

thanks for your detailed explanation.

On Friday, November 22, 2013 6:53:53 PM UTC+1, Bob Nystrom wrote:

On Thu, Nov 21, 2013 at 11:06 AM, Günter Zöchbauer <gue...@gzoechbauer.com> wrote:

dependencies:

  foo: >2.0.0

If there exists a 2.0.1 and then is a 2.0.2 published pub will not upgrade.

No, if you run pub upgrade here, it will upgrade to 2.0.2. What it won't do is upgrade to 2.0.2-scary if 2.0.1 exists.

Sorry for my lame example. The example you gave was what I actually wanted to discuss.

If I would find 2.0.2-xxx scary I would not have started working with Dart before version 3.87 was out for at least 6 months anyways ;-)

What I miss now is that I have no tooling support to see if something is going on when package developers publish dev releases.

Updates are easy to miss when I have to check manually and I may work towards a dying APIs when I easily could have gone with the new 'scary/unstable' one at the first place,

or that I waste time finding workarounds, just because I didn't know there is already an intermediate fix available.

I don't think that this is going to be a big issue.

I just thought this would be interesting for others too and that it is not too hard to solve.

If Dart has no built-in support for this I may build something by myself. Should not be to hard.

Maybe nobody will ever release dev versions anyway.

Günter

[Bob Nystrom]

On Mon, Nov 25, 2013 at 11:59 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Sorry for my lame example. The example you gave was what I actually wanted to discuss.

If I would find 2.0.2-xxx scary I would not have started working with Dart before version 3.87 was out for at least 6 months anyways ;-)

Heh, understood. :) But Dart is now at 1.0.0 and packages are starting to reach stability too. We're entering a world where some Dart users do want stability. They expect things to work and keep working.

For those people, I think it makes sense for pub to avoid development versions when possible. For people that do want to be on the bleeding edge, of course, they need access to development versions. (Otherwise there would be no point in publishing them at all!)

The only question is which behavior is the default. I think it makes sense for pub to default to stability and let users opt in to unstable versions (by specifying a version constraint that only contains unstable versions). My reasoning is two-fold:

1. 1. I expect that most people will prefer stable versions, so defaulting to that minimizes the work that most people have to do.
   
   
2. If we default to giving users unstable versions, then package authors know that as soon as they publish a dev version with some random experimental stuff, it will immediately start breaking new users. That gives them a strong disincentive to publish unstable changes.
   
   That means that packages will either evolve very slowly (by never pushing out anything unstable) or in ways that haven't been actually validated with real world feedback (by pushing out untested changes and then promising to support them forever).
   
   I don't think that's good for the package ecosystem. I want package authors to be able to move quickly, get feedback from users, and iterate on their APIs as easily as possible. I think the only way to do that is to insulate most users from those changes. 

What I miss now is that I have no tooling support to see if something is going on when package developers publish dev releases.

Updates are easy to miss when I have to check manually and I may work towards a dying APIs when I easily could have gone with the new 'scary/unstable' one at the first place,

or that I waste time finding workarounds, just because I didn't know there is already an intermediate fix available.

This is a totally valid concern. One thing I'd like to add is the ability to run pub upgrade --dry-run so you can see if your package could upgrade a dependency. This still requires explicitly doing this, though.

I'm up for more proactive ways of letting people know that they are using older versions of stuff. We just have to balance that with not bugging people who don't want to upgrade. After all, if your program is in maintenance mode, you don't want to upgrade. If it ain't broke, you don't want to spend time fixing it.

If Dart has no built-in support for this I may build something by myself. Should not be to hard.

What did you have in mind? I would love to have more external contributors to pub and if it makes sense to put it there, I can help walk you through sending us a patch.

 

Maybe nobody will ever release dev versions anyway.

They most definitely will. I know the polymer folks in particular need this because they are squeezed between having lots of actual users shipping apps but also being bleeding edge technology with high API churn.

Cheers!

- bob

[Günter Zöchbauer]

Hi Bob,

What you wrote seems to be exactly what I wish for.

The default behavior doesn't matter at all if I can override it.

Currently I have a script I run daily which runs pub upgrade for every package, I don't mind adding another parameter.

If I get notified about possible upgrades (e.g. pub upgrade output) I can manually update the version constrains too if necessary.

But I won't/can't check manually if a new release I use somewhere or a transitive dependency of it was made available.

I would write a dirty hack that just does what I need probably not suitable for publishing ;-).

I would love to contribute more and learn more 

but I have enough on the platter for now especially until polymer-elements are ported.

And I have to find a way to make a living too which I currently haven't.

Günter

[Kasper Lund]

On Wed, Nov 20, 2013 at 8:06 AM, Rico Wind <ri...@google.com> wrote:
> The first new full release (i.e., the first 1.1 release) will be arriving on
> dev channel in the coming weeks. If you are currently on dev channel and
> wish to switch, you need to go download the stable version from the webpage.

The first dev channel release on the path towards version 1.1 has been
released (1.0.1.3) today. For the first time ever there are now
substantial differences between the stable and the dev channel
releases.

If you feel a little bit adventurous, please take the new dev channel
release for a spin and give us feedback so we can make the next stable
channel release rock solid. If you are currently on the dev channel
but you wish to downgrade to the stable channel, you can always fetch
the latest stable bits from https://www.dartlang.org/.

Cheers,
Kasper

[Rob Bishop]

pub upgrade crashes (command line)... see

https://code.google.com/p/dart/issues/detail?id=15351

--
For other discussions, see https://groups.google.com/a/dartlang.org/

For HOWTO questions, visit http://stackoverflow.com/tags/dart

To file a bug report or feature request, go to http://www.dartbug.com/new

[Matthew Butler]

\o/ But is there a chagelog somewhere to see what updates have been made to the Dev version (eg: areas we can check to see if things are fixed or things are broken? ;)

[Kasper Lund]

On Wed, Nov 27, 2013 at 2:18 PM, Matthew Butler
<butler....@gmail.com> wrote:
> \o/ But is there a chagelog somewhere to see what updates have been made to
> the Dev version (eg: areas we can check to see if things are fixed or things
> are broken? ;)

We do plan to send out release notes along with both dev channel and
stable channel releases. We're still trying to figure out what level
of information would be most useful (individual changes, higher level
notes, or both?). If you can tell us what you'd like to see that would
be very valuable feedback for us.

Cheers,
Kasper

[Matthew Butler]

On Wednesday, November 27, 2013 9:49:42 AM UTC-4, Kasper Lund wrote:

On Wed, Nov 27, 2013 at 2:18 PM, Matthew Butler
<butler....@gmail.com> wrote:
> \o/ But is there a chagelog somewhere to see what updates have been made to
> the Dev version (eg: areas we can check to see if things are fixed or things
> are broken? ;)

We do plan to send out release notes along with both dev channel and
stable channel releases. We're still trying to figure out what level
of information would be most useful (individual changes, higher level
notes, or both?). If you can tell us what you'd like to see that would
be very valuable feedback for us.

Cheers,
Kasper

Personally to me I think individual changes for the dev channel. And higher level notes for stable channel.

My reasoning: Dev channel are 'testers' living closer to the bleeding edge to get the latest changes and updates and instability to a degree. Helping find potential bugs etc. It's good to have the details going into each release.

Stable you're looking to keep relatively calm and comfortable for development. You want a quick overview of what changed but so granular that it gives you too much to consider using the release. You want it to 'just work'.

Just my $0.02CDN

Matt 

[Rob Bishop]

I agree with Matt.  

It's what I was trying to get at with https://code.google.com/p/dart/issues/detail?id=15131

Sometimes us early adopters are waiting on a particular fix (or set of fixes) in a particular package or piece of the SDK.  We just desire a relatively easy way to figure out what made it in to the latest release we're using.  Going straight to the GitHub history helps a lot but that's not so easy to find and still kind of fragmented.  A list of rXXXXX's (or r-ranges) in the dev release notes would be ideal, so we could just look then up on the Changes page.   

--

[Matthew Butler]

FWIW, while not an official changelog, this issue search will display items marked as 'fixed' for 1.1 release. And most (though probably not all) items should be in today Dev release.

https://code.google.com/p/dart/issues/list?can=1&q=label%3AMilestone-1.1+Status%3AFixed&sort=-status&colspec=ID+Type+Status+Priority+Area+Milestone+Owner+Summary&cells=tiles