-
-
Notifications
You must be signed in to change notification settings - Fork 71
Release 6.6 #1352
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
Release 6.6 #1352
Conversation
✅ Deploy Preview for ember-blog ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| Today the Ember project is releasing version 6.6 of Ember.js and Ember CLI. | ||
|
|
||
| This release kicks off the 6.7 beta cycle for all sub-projects. We encourage our community (especially addon authors) to help test these beta builds and report any bugs before they are published as a final release in six weeks' time. The [ember-try](https://github.com/ember-cli/ember-try) addon is a great way to continuously test your projects against the latest Ember releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update this? The 6.7 beta cycle is now over...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, but I think there's some inherent tension here around what constitutes the release. I know a release isn't considered "done" until we do the learning portion, but I wonder if we need to re-consider what the blog post means. Is it documentation about what did happen? Is it a directive only about what will happen? I think the language leans towards the latter, but in practice since we're (I am) often late and source and cli were released, it's also the case that it serves to document what has already happened. The blog post doesn't change the fact that 6.6 was released 7/21 and a beta cycle was completed. I wonder in these situation if we can describe highlight the delayed blog post.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe marking the release post as late and/or historical makes sense. I think what I'm looking to avoid is correcting for accuracy, but then also creating other issues. Like if we just adjusted the version the communication around 6 weeks probably doesn't make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Traditionally we've considered the blog post releasing to be 'done' but the release of 'ember-source' to be the marker of the 6 week cycle. We did this after very many releases that were late (not due to learning in those days), so I just think the wording here is odd.
This could be something like:
A release of Ember is comprised of many projects: ember-source, ember-cli, api docs, guides, etc. We follow a [6-week release train](prob somewhere to link here) that includes alpha and beta cycles to ensure changes are well-tested. We encourage our community (especially addon authors) to help test the beta builds and report any bugs before they are published as a final release. The ember-try addon is a great way to continuously test your projects against the latest Ember releases. While we consider the release to be complete upon publication of the blog post but the 6-week cycle is anchored by the release of the ember-source package.
No description provided.