Sitelet https://github.com/nodejs/node/issues/305
Skip to content

assemble a changelog for 1.0.0 #305

Description

@rvagg

We need to decide what the changelog contains and who does he work of putting it together.

  • all changes since v0.10?
  • all changes since v0.11.14?
  • all changes landed specifically in iojs/io.js as distinct from joyent/node?

The problem is of course that we have a whole community used to 0.10 and we're a very long way from there now. Do we just link to the joyent/node wiki page on the differences and let people figure it out? Perhaps er just limit ourselves to broad themes?

I'd love for someone to step up and craft an artisnal changelog for this release, but if nobody does I'll try and find a spare moment to churn something out.

Then there's the matter of some kind of release announcement coupled with this ...

Activity

  1. added this to the milestone on Jan 12, 2015
  2. fzaninotto commented on Jan 12, 2015

    @fzaninotto

    I suggest that you focus here on the differences between Node.js and io.js (prop. 3), and link to the Node repository for the changelog since 0.10.

    That's a good way to show that you are compatible with Node.js, and that you only add your layer on top of Node.

    That's also what I, as a Node user, would like to see first on your site.

  3. domenic commented on Jan 12, 2015

    @domenic
    Contributor

    I would expect a changelog since Node.js 0.10.35.

  4. snostorm commented on Jan 12, 2015

    @snostorm

    I've said this a few times around various parts of the io.js projects, but I think we could take some inspiration from https://developer.mozilla.org/en-US/Firefox/Releases -- especially how they list future versions along side stable ones. (The one thing I don't like is their table layout which does nothing to indicate stable/not/release-dates.)

    But it would be nice to start laying out what is (expected to be) coming on each scheduled release, especially with the recent ES6 feature concerns, etc. This can help communicate to the community to begin playing with feature flags, unstable APIs, etc. and provide feedback. What is also nice in their documentation is knowing when previously unstable/flagged things are getting promoted, say in the "February 2015" release.

    Anyway, long story short, once in the web project we can get more of a build process/design structure in place, I'd be happy to help start laying this out. First thing's first -- getting the core content together. Perhaps somebody can start the v1.0 changelog in the wiki and PR that content to master once some rounds of edits go through?

  5. fixe commented on Jan 12, 2015

    @fixe
    Contributor

    Agree 100% with @fzaninotto.

  6. bnoordhuis commented on Jan 13, 2015

    @bnoordhuis
    Member

    Has anyone been working on this yet?

  7. rvagg commented on Jan 13, 2015

    @rvagg
    MemberAuthor

    no

  8. rvagg commented on Jan 13, 2015

    @rvagg
    MemberAuthor

    working in #339

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions